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

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



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.

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.
This is indeed a questionable behaviour.  What are other things people
want to do in a sighandler?

  a) set a variable;
  b) increment a variable;
  c) exit();
  d) wait() and assign the result;
  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.  This leaves 'f', which is much better in
your setup.

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

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

Ilya


Follow-Ups from:
Dan Sugalski <dan@sidhe.org>
Larry Wall <larry@wall.org>
References to:
Ilya Zakharevich <ilya@math.ohio-state.edu>
Larry Wall <larry@wall.org>

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