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

[Larry Wall <larry@wall.org>]

Ilya Zakharevich writes:
: On Tue, Jan 11, 2000 at 10:31:36AM -0800, Larry Wall wrote:
: > Existing XS code is a problem regardless.  Inventing a new minilanguage
: > does not solve this.
: 
: Of course immediate atomic delivery solves this, as well as removes
: the complexity of intentional slowing-down of tight loops.

But your delivery doesn't deliver, in the sense of guaranteeing the
script will notice the signal any time soon.  My scheme is also does
atomic delivery, only not to Perl, but to a C array and a global, which
we then take pains to check periodically.

: > First, we can do the deliver-immediately-on-duplicate-signal trick.
: > That could be generalized to deliver immediately on any second signal if
: > sufficient time has passed, provided time() is a safe system call.
: 
: If this delivery is unsafe, then this is just putting things under the carpet.

As I recall, you're the one who proposed immediate delivery on a second
signal not so very many messages ago.

: > As far as I'm concerned, the main remaining issue is how to direct
: > signals to a particular thread.
: 
: Let me repeat one of the reference points: close to impossible under OS/2.

Let me point out that we don't have to deliver C level signals to
another thread.  We only have to deliver Perl level signals.  My
proposal divorces the two.  The C signal comes in on whatever thread
happens to be running at the time, and atomically sets up the Perl
signal.  Then all other Perl threads simply ignore the signal until the
signal thread wakes up.  At worst this depends on the latency of the
scheduler, and remains completely safe.

Larry

---

Follow-Ups from:

Ilya Zakharevich <ilya@math.ohio-state.edu>

References to:

Ilya Zakharevich <ilya@math.ohio-state.edu>

---

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

---