Re: Help repro PR 1749.

[Kaz Kylheku <kaz at ashi dot footprints dot net>]

On Sat, 29 Jul 2000, Roland McGrath wrote:

> Date: Sat, 29 Jul 2000 18:18:52 -0400 (EDT)
> From: Roland McGrath <roland@frob.com>
> To: Kaz Kylheku <kaz@ashi.footprints.net>
> Cc: libc-alpha@sourceware.cygnus.com
> Subject: Re: Help repro PR 1749.
> 
> > Internally, the condition wait function actually thinks that it has been
> > removed from the queue and signalled, which is not the case. 
> 
> You mean it leaves some dangling pointers to the current thread on a queue?
> 
> > Perhaps I should have called this an erroneous return rather than a spurious
> > wakeup; sorry about the confusing terminology!
> 
> It is not the return that is erroneous.  It is the dangling state.

No; if the program calls functions from within a signal handler, which
are not on the list of async safe functions, it is the program that
is erroneous!

> The return would be ok if it cleaned up state, so if it is easier to
> fix it that way than to make it know when to continue blocking,
> that is an ok fix.

You can't clean up the state, because the signal could arrive at any time.
For example the thread could be in the middle of queuing itself on the
condition variable when it gets the SIGINT. The handler the calls printf
which calls into pthread_mutex_lock, making a mess out of everything
since the same queuing pointers are used for pthread_mutex_lock as
for the lock around the condition variable queue.