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

[Dan Sugalski <dan@sidhe.org>]

At 11:17 AM 1/12/00 -0500, Joshua N Pritikin wrote:
>On Wed, Jan 12, 2000 at 10:56:06AM -0500, dan@sidhe.org wrote:
> > At 10:35 AM 1/12/00 -0500, Joshua N Pritikin wrote:
> > > > 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.
>
>I don't know.  At least the control is in the hands of the developer. On
>the other hand, perhaps POSIX provides this as an option too.  I am
>hardly qualified to debate this stuff.

Well, POSIX doesn't, really. More to the point it explicitly makes the 
"what thread gets a signal" implementation-defined. So what Linux is doing 
is mostly OK, except it's my understanding that signals are supposed to 
roll over--if they get popped to a thread that's blocked that particular 
signal then the signal isn't supposed to be lost, instead sent to another 
thread.

I think part of this is to accommodate those systems that use a LWP/Kernel 
thread scheme--the signal goes to the process/KT and gets delivered to the 
first thread that runs on that process/KT that's set itself to handle the 
signal.

POSIX threads are a sort of cross-platform compromise. Not 100% great, but 
workable on a wide range of OS/platform setups. Which does mean that Linux 
can do it better since it's a private implementation, but the problem is 
they fib and say they're POSIX (and thus you'd expect them to behave in the 
POSIX manner) but they really aren't.

> > >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.
>
>I'm still mystified.  Obviously the library/kernel can do this
>automatically but what is so hard about doing it at the application
>level?  Wouldn't it just be a matter of adding a bunch of handlers
>to the children threads:
>
>   static Signal_t process_sighandler(int sig) { kill(ParentPID, sig); }
>
>Am I missing something?

Nope. But that's error prone and, more to the point, platform-specific in a 
way it shouldn't be if it's really POSIX threads. (And I'm not sure that 
the parent pid's set right, but you can always set the signal thread pid in 
a global somewhere and work with that)

Not that we can't (or shouldn't) deal with it at the perl level, of course. 
Just an annoyance.

					Dan

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

---

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]

---