>>>>> On Thu, 10 Aug 2006 10:11:55 +0200, Jan Djärv <[EMAIL PROTECTED]> said:

>> Maybe I'm missing something, but doesn't adding BLOCK_INPUT around
>> closedir (and opendir) help?

> In this particular case it would help, but in general the problem is
> that the signal handler gets called when the main thread is
> executing in the mutex code (pthread_mutex_unlock).  Later when the
> signal handler tries to get the mutex, it locks up,

My intention was that the above scenario would be avoided with
BLOCK_INPUT around functions that may call malloc-related functions.

> it is actually not allowed to call mutex functions from a signal
> handler.  The mutex is there to protect from other (Gnome) threads
> that also call malloc/free.

> But if a Gnome thread has the mutex and before it has blocked
> signals, the signal handler is run in parallell on another
> processor, there will be problems.  If we move to SYNC_INPUT there
> will be no malloc/free called in the signal handler and we only need
> the mutex to hamdle concurrent access.

The current version would cause such a problem because now
BLOCK_INPUT_ALLOC and UNBLOCK_INPUT_ALLOC are no-op in a signal
handler.

How about just changing the order of lock/unlock and
BLOCK_INPUT/UNBLOCK_INPUT in the previous version of
BLOCK_INPUT_ALLOC/UNBLOCK_INPUT_ALLOC?

#define BLOCK_INPUT_ALLOC                       \
  do                                            \
    {                                           \
      if (pthread_self () == main_thread)       \
        BLOCK_INPUT;                            \
      pthread_mutex_lock (&alloc_mutex);        \
    }                                           \
  while (0)
#define UNBLOCK_INPUT_ALLOC                     \
  do                                            \
    {                                           \
      pthread_mutex_unlock (&alloc_mutex);      \
      if (pthread_self () == main_thread)       \
        UNBLOCK_INPUT;                          \
    }                                           \
  while (0)

                                     YAMAMOTO Mitsuharu
                                [EMAIL PROTECTED]


_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Reply via email to