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

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

On Wed, Jan 12, 2000 at 11:01:16AM +0000, Tim.Bunce@ig.co.uk wrote:
> On Tue, Jan 11, 2000 at 02:06:52PM -0800, Larry Wall wrote:
> > Ilya Zakharevich writes:
> > : We *need* an event loop in Perl core - or very close to it.  This may
> > : be a part of this loop.
> > 
> > Indeed, that's what the perl-loop mailing list has been working on for
> > lo these many months.  Any folks from perl-loop want to comment?
> 
> My (vague) impression is that that work fragmented with one group adding
> features and others being unhappy that there were too many features.
> I think it's lost direction and consensus support. Sadly.

That's news to me.  Granted, there was heated discussion for a few
months but I believe most folks are now mostly satisfied with the design
and implementation.  Graham, Nick, Gisle and others, feel free to
correct me or forever hold your peace.  ;-)

Speaking to the topic of this thread, I'm not sure how much help Event
is to solve the lack of bullet-proof signals.  Furthermore, Event tries
to ignore the implications of multiple threads as much as possible.  I
envision Event running in a single thread and using thread-safe queues
(or whatever) to dispatch to worker threads.  As far as signal handling,
I have implemented a signal watcher that reliably generates events for
signals.  The signal handler is as follows:

static Signal_t process_sighandler(int sig) {
    pe_sig_stat *st = &Sigstat[Sigslot];
    ++st->Hits;
    ++st->hits[sig];
}

The fancy stuff with Sigslot avoids any chance of loosing signals during
inspection of the signal counters.  The signal counters are polled every
iteration through the event loop.  This works well for easy stuff,
meaning, your code is Event driven and doesn't care about signal
latency.  My hope was that run-time opcode substitution would give us
more ways to cope with these nasties.  Where does that patch stand?

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.  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.

I have little idea about Win32.  Personally, I am not interested in
doing a port.  No volunteer has stepped forward so perhaps we can strike
a deal with Microsoft to commission the work.  At least I can parrot
from those more knowledgable that the Win32 model is *significant*
different than Unix.  We may want to consider exposing another level of
abstraction to the programmer.  I'm not sure we can present a
consistent, portable interface without loosing OS specific
optimizations.  At least the decision should be put off until someone
understands all the issues and can say something definite.

Lastly, I want to make sure that no one forgets about a handler to print
the perl stack upon SIGSEGV.  Of course perl should never cause a
SIGSEGV, and I trust that p5p (and p6p) can probably assure this, but I
fear we also have to consider the unwashed masses of XS authors (myself
included :-).

If you have any further questions, I'd be happy to share my thoughts.
Hope this helps.

-- 
"Never ascribe to malice that which can be explained by stupidity."
                            via, but not speaking for Deutsche Bank

---

Follow-Ups from:

Graham Barr <gbarr@pobox.com>
Dan Sugalski <dan@sidhe.org>

References to:

Larry Wall <larry@wall.org>
Tim Bunce <Tim.Bunce@ig.co.uk>

---

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

---