Re: Locking again

On 08.08.2002 06:59 Carlos Morgado wrote:
> On 2002.08.08 11:30:46 +0100 Emmanuel wrote:
>> 	Hi all,
>> I would suggest a (temporary) fix for the locking problem : we should 
>> just not drop the gdk lock before calling the imap functions at the 
>> very beginning. This is not optimal from a performance viewpoint but as 
>> we know we'll need it in the middle of the mutt transaction (i.e. with 
>> the mutt
> that was the old way, it sucked the life out of the UI. meanwhile pawel
> cunningly moved the UI stuff to the main thread so that we don't need
> the gdk lock in *that* thread. seems to work :)

OK to be sure I understand well the following code :

libmutt_ask_for_cert_acceptance(X509 *cert)
     static pthread_mutex_t ask_cert_lock = PTHREAD_MUTEX_INITIALIZER;
     AskCertData acd;

     if (pthread_self() == libbalsa_get_main_thread())         return 

     libbalsa_unlock_mutt(); gdk_threads_leave();
     pthread_cond_init(&acd.cond, NULL);
     acd.cert = cert;
     gtk_idle_add(ask_cert_idle, &acd);
     pthread_cond_wait(&acd.cond, &ask_cert_lock);
     gdk_threads_enter(); libbalsa_lock_mutt();
     return acd.res;

the if statement is there because this func may be called from the main 
thread, and in that case we can call directly the UI stuff (there is no 
threading problem here) [Moreover we would have a deadlock if we did the 
second part, because we would stop the main thread and wait indefinitely 
for the gdk unlock].
The second part seems OK but this : why do we unlock gdk ? This part must 
be called from another thread (not the main one), i.e. a backend thread 
that should not have the gdk lock. So IMHO we should not lock gdk in the 
backend thread, only in the UI func (the idle handle); moreover that way 
we would avoid the unlocking of libmutt that seems rather risky.
Does that sound correct?

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]