emacs-pretest-bug
[Top][All Lists]
Advanced

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

Re: Lockup


From: YAMAMOTO Mitsuharu
Subject: Re: Lockup
Date: Fri, 11 Aug 2006 16:12:31 +0900
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/22.0.50 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)

>>>>> On Fri, 11 Aug 2006 08:36:39 +0200, Jan Djärv <address@hidden> said:

> A signal yes, but I was thinking of this scenario:

> A Gnome thread does malloc, gets the mutex lock and enters the
> malloc code.  A signal is delivered (in the main thread as you point
> out) and enters malloc also.  This situation is exactly like the one
> with the lockup, but here we can't use BLOCK_INPUT around the malloc
> related functions because they are in the Gnome code.

I think such a case just behaves like a usual mutual exclusion between
multiple threads: one thread acquires a mutex, and the other blocks
until it is released.

> I agree with your assumtion that the lockuo occurs because the
> signal handler and the interrupted therad are calling
> pthread_mutex_(un)lock for the same mutex.  But BLOCK_INPUT does not
> help, because Gnome code does not have it.

That's not a problem because Gnome threads (non-main threads) never
execute pthread_mutex_(un)lock in the signal hander context.

                                     YAMAMOTO Mitsuharu
                                address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]