[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]