[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



Ilya Zakharevich writes:
: > This has all been discussed before.  We need to delay sub invocations
: > until we know we're in a safe state, such as the beginning of a
: > statement, or at the interator of any looping constructs, including
: > regular expressions.
: 
: No, we do not *need* to delay sub invocations.  Delaying the
: invocation is one of the possible workarounds to the current
: disaster.  It has many negative effects, like being a NOP in the case
: of a long-running opcode.

And in what way does your proposal help this?  What interrupts the
long running opcode in your version of reality?  You modified some
existing variables, so what?

: And if you want the delayed semantic, you may do 
: 
: $SIG{CHLD} = [delayed => sub {...} ];
: 
: And you can do
: 
: $SIG{CHLD} = [delayed => sub {...}, repeated => [2, sub {...}] ];
: 
: which might mean that if another signal appears when one is delayed
: (meaning: AHA, something dangerous happens: signal was not served,
: probably a long-running opcode, we need some recovery action), another
: sub (or maybe another %SIG-compatible specification, as at the start)
: should be run.

That's more needless complexity.  This should be hidden from the user.
Immediate dispatch on duplicate signals could be done in the current
scheme as well without exposing it to the poor user.  And that's only
necessary if we aren't smart enough to find all the proper check
points, which I think we are.

: > Of course, within regular expressions we'd have
: > to take extra care to be re-entrant, but the swash routines already do
: > that now--see Perl_save_re_context().
: 
: Which is an obvious bletch.

But then you're talking implementation again.  I'd rather see the
complexity in the implementation than in the interface.  Perl was
intended to be easy to use, not necessarily easy to implement.  Of
course, for a given interface, a simpler implementation is nice, but
that's not what we're optimizing for.

And the whole idea of signals is so busted anyway that I don't think a
complex interface is worth it.  Save the TMTOWTDI for more important stuff.

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]