Re: why "in_sighandler"?

[Jan Djärv]

YAMAMOTO Mitsuharu skrev:
> > > > > > On Mon, 21 Aug 2006 08:18:38 +0200, Jan Djärv <address@hidden> said:
>
> > I don't like it, because it assumes things are "probably OK" to run
> > in the signal handler (i.e. pthread_mutex_lock/unlock).  I still
> > think it might hang if a Gnome thread is in mutex_lock and a signal
> > arrives and then the signal handler also enters mutex_lock.
>
> Does it mean the quote from IEEE Std 1003.1 did not convince you?

In a way, but not the same way you interpret it :-).  The quoute is:

  "All functions not in the above table are considered to be unsafe
  with respect to signals. In the presence of signals, all functions
  defined by this volume of IEEE Std 1003.1-2001 shall behave as
  defined when called from or interrupted by a signal-catching
  function, with a single exception: when a signal interrupts an
  unsafe function and the signal-catching function calls an unsafe
  function, the behavior is undefined."

Read the single exception:  "when a signal interrupts an
  unsafe function and the signal-catching function calls an unsafe
  function, the behavior is undefined."

This is exactly what happens if a Gnome thread enters pthread_lock/unlock and 
a signal arrives and the signal handler later also calls pthread_lock/unlock. 
 This was the original problem.


> > It is one assumtion against another, neither suggestion is without
> > flaws (we need SYNC_INPUT for that).
>
> No assumption is needed to say that the current code leads to a
> problem under a certain scenario.

No, but in the presense of signal handlers executing malloc, there is no 
scenario that is safe.  Your suggestion also has undefined behaviour accoding 
to the quote from the standard.  The one currently implemented has a race 
condition.

> Suppose that we abandon emacs_blocked_malloc and so on when
> HAVE_GTK_AND_PTHREAD is defined.  I think it is as safe as other
> non-GNU-malloc systems where emacs_blocked_malloc and so on are not
> used, provided that malloc-related functions are thread-safe.  What do
> you think about that?

This whole workaround with mutexes and blocks started because Emacs hanged on 
some system, I'm not sure if it was a GNU/Linux system or some kind of BSD 
variant.  So I don't think we should go back, the old problem happend every 
time the file selection box was opened on a Gnome system.

        Jan D.