Signals and threads just don't mix. Signals terminate many system
calls with EINTR (for example). Multiple threads can receive the
signal, including every thread _but_ the one you really want to see
the thing.
I've been doing threads for a long time, dating back to Cray's first
version of Unicos. I found that signals are simply something to be
completely avoided if threads are being used.
Robert Hyatt Computer and Information Sciences
hyatt@cis.uab.edu University of Alabama at Birmingham
(205) 934-2213 115A Campbell Hall, UAB Station
(205) 934-5473 FAX Birmingham, AL 35294-1170
On Tue, 23 May 2000, Brian Pomerantz wrote:
> On Tue, May 23, 2000 at 11:50:51PM -0400, Brent Verner wrote:
> > on Tue, May 23, 2000 at 05:54:26PM -0700, Reto Baettig typed aloud:
> > |
> > | Description:
> > | ------------
> > | See attached example.
> > | The threads are waiting for a condition. When I press CTRL-C, sometimes
> > | the
> > | threads waiting for the condition "wake up". This happens almost
> > | everytime on
> > | Alpha SMP and happens sometime on Alpha UP. I could not try Intel SMP
> > | yet. Intel UP seems to work fine (but one never knows ;-)
> >
> > (feeling silly for replying so hastily...)
> >
> > ah, I understand (now, after running the test code). I'm seeing that _all_
> > threads are running the sighandler, instead of one This smells like a bug
> > to me after verifying that the code runs as expected when compiled under
> > freebsd.
> >
> > Is this a known 'issue' with linuxthreads?
> >
>
> That isn't the only "strange" behavior. Not only does the signal
> handler run on all threads, but sometimes (most of the time on the
> ES40's we've tested this with) the pthread_cond_wait() call in the
> foo() function mysteriously falls through as if there were a
> pthread_cond_broadcast() called in the signal handler. This certainly
> must be a bug. I did try masking off the SIGINT signal before
> entering the for(;;) loop and that seems to fix the
> pthread_cond_wait() from falling through.
>
>
> BAPper
> -
> Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/dmentre/smp-howto/
> To Unsubscribe: send "unsubscribe linux-smp" to majordomo@vger.rutgers.edu
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:11 EST