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 01:03:04PM -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.
: 
: It is good that our schemes are so close.  But mine is better ;-): you
: do not need to check things periodically.

Only for some values of "you".  If you increment a variable then some
value of "you" has to write code to check the variable.  In my proposal
Perl checks it for you.

: First I failed to see how your scheme will make script notice the signal.
: Later I realized that you probably you mean die() here:
: 
:   $SIG{} = [die => $message];
: 
: will die atomically, but may leave things in a non-consistent state.

Eh?  I never said anything like that...

: This is indeed a questionable behaviour.  What are other things people
: want to do in a sighandler?
: 
:   a) set a variable;

Forcing the script to check the variable periodically.

:   b) increment a variable;

Forcing the script to check the variable periodically.

:   c) exit();

Can be optimized away as a subroutine with a known constant value.  :-)

:   d) wait() and assign the result;

Again, somebody's gotta check for the result explicitly if they care.

:   e) wait() and append the result to an array/hash;
:   f) die with a message;

: All things in a)..d) can be made atomically without any damage.  e)
: can be done atomically if the array/hash is tied to something which
: allows an atomic update.

Seems unlikely, since you probably have to allow malloc in there somewhere
to grow the array, unless you're journaling to disk, which seems relatively
useless, or allocate a fixed size array, which can drop signals.

: This leaves 'f', which is much better in your setup.

And you left out:

    g) anything else you might want to do safely in a signal handler.

: So question is: are we going to make a major rewrite just to allow
: really-safe die() in a signal handler?

I don't think it's a major rewrite.

All we have to do is make sure our check points can reach a consistent
state if they need to.  So the check point in sort may have to switch
stacks, for instance.

: > : 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.
: 
: Not a tiny bit easier: you still need to unblock the thread.

How does OS/2 unblock a thread?  Obviously it can, or threads would never
run.  How about if the signal-handling thread is waiting on some I/O that
another thread can provide?

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]

---