Re: A few remarks about locking

[Emmanuel <e allaud wanadoo fr>]

On 26.03.2002 09:42 Pawel Salek wrote:
> On 2002.03.25 16:54 Emmanuel wrote:
>> It's written in a comment before the function 
>> libbalsa_mailbox_load_messages(LibBalsaMailbox * mailbox) (in 
>> libbalsa/mailbox.c) that it must be called with the gdk lock held. But 
>> I think it's false. In fact I even try it without the gdk lock and it 
>> works perfectly. I think that it is because we don't use any UI 
>> function (we only emit signals and process the libmutt headers).
> 
> Just remember that the signal handlers may call GDK functions.

Yes you're right.
But if you look at libbalsa_mailbox_load_messages, the big loop does not 
call gtk (AFAICS) so we could release the lock before it and reclaim it 
after. I think this improves a bit the UI interactivity for huge mailboxes.
The same if we look at libbalsa_mailbox_local_check (in 
libbalsa/mailbox_local.c). We never release the gdk lock in this function, 
but mx_check_mailbox can be quite long and AFAIK it does not call gdk so 
we could release the gdk lock during this call and reclaim it after.

>> But what seems strange to me is that in this function we process 
>> libmutt datas without holding the mutt lock, is this correct (think of 
>> another thread calling libmutt to change the same mailbox --> big mess).
> 
> Yes, libmutt lock would not hurt there I guess (OTOH, the client context 
> is locked by using LOCK_MAILBOX()).
> 
OK but a concurrent call to libmutt could change the datas referenced by 
the context. So for example you could have you context saying that you 
have 100 messages, then you go for the loop and in the meantime another 
thread call libmutt and delete one of the messages and you will try to 
access a header that no more exists. That sounds possible at least to me.
Bye
Manu