Re: [ID 19991229.003] perl 5.005_03 core dumps -- signal

[Dan Sugalski <dan@sidhe.org>]

At 10:35 AM 1/12/00 -0500, Joshua N Pritikin wrote:
>On Wed, Jan 12, 2000 at 10:18:24AM -0500, dan@sidhe.org wrote:
> > At 09:54 AM 1/12/00 -0500, Joshua N Pritikin wrote:
> > >I usually give up at this point because I can see that signals are a
> > >mess and getting them to work with multiple threads is going to make it
> > >worse.  I am encouraged to hear that linux does not follow POSIX.  My
> > >experience with POSIX threads has not been very encouraging.
> >
> > I wouldn't get too encouraged. Linux threads are an attempt to shoehorn
> > POSIX threads onto a system that actively disapproves of them. The big
> > issues are signals and process table exhaustion, but there are other 
> niggly
> > things. (Each thread has a separate pid, for example, and the kernel
> > doesn't really know what 'process' a thread belongs to)
>
>So what?  I know (from kernel traffic) they are aware of and fixing the
>process table exhaustion...

Good. I hadn't seen that, but I only skim the weekly summaries occasionally.

> > >My
> > >unsubstantiated suspicion is that the POSIX thread spec was written well
> > >ahead of any working implementation. I think it is likely that the linux
> > >model is better even though I haven't checked myself.  This is just a
> > >vague feeling.  I might be completely backwards here.
> >
> > In some ways its worse. Because threads are really separate processes,
>
>What's the difference?  Memory sharing is the same, right?

Yes, though there's more to a thread than memory sharing. (You can 
currently flock yourself into a deadlock too, FWIW, though hopefully 
they're fixing that, too)

> > only the thread that actually gets the signal delivered can see it.
>
>Yes.  That's one of the reasons I felt that linux might be an
>improvement over the POSIX mess.

In some ways it is, for the synchronous signals--they're more installed 
error handlers than anything else. Async signals, on the other hand, are 
events rather than errors, and are delivered to the *process*, not to the 
thread. Who should get SIGHUP, or SIGCHLD, or SIGCONT, or SIGIO? These all 
deal with process-level events, and the thread that was responsible for 
them being generated (if you can even figure that out easily) isn't 
necessarily going to be the one that should handle them.

> > Not
> > necessarily a bad thing (though it makes separate signal-handling threads
> > trickier)
>
>I never understood the alure of routing all the signals to a single
>signal-handling thread.  Can anyone comment on this?

It makes handling the event signals easier. You just route 'em all to a 
single thread that deals with them, rather than having to cope with them in 
all your threads.


					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                      teddy bears get drunk

---

Follow-Ups from:

Joshua N Pritikin <joshua.pritikin@db.com>

References to:

Dan Sugalski <dan@sidhe.org>
Joshua N Pritikin <joshua.pritikin@db.com>
Joshua N Pritikin <joshua.pritikin@db.com>

---

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]

---