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