Front page | perl.perl5.porters |
Postings from January 2001
nick@ing-simmons.net wrote:
> >I'm waffling between checking between every op, or having an op that
> >explicitly checks. (Possibly the end-of-statement cleanup op would do this)
>
> FWIW - current perl5.7.* development sources so the signal stuff every op.
> i.e. we should have "safe signals" now.
> (Which makes the sigsetjmp vs setjmp even less interesting as C level
> handler does neither.)
Sounds good!
> >>In other words the C level signal handler will have to do no more than
> >>setting a flag, as will the implementation of die().
>
> You need to explain the die case some more.
> Consider:
>
> if (sv == NULL)
> {
> Perl_die("Something is not valid");
> }
> iv = SvIV(sv);
>
> With the perl5 scheme the die longjmp()s away from the segfault.
> So the implementation of "die" has to do more than set a flag.
> It has to "noop" the code untill we reach a cancellation point.
> It also has to save the "context" (file, line) and/or the "message".
> It will end up looking like Tcl core... i.e. just about everything
> returns not the value you wanted, but a flag to say whether it died
> or not - I guess the flag could be in the "interpreter" data structure,
> but you are still going to have to test it.
I think we need to distinguish between dies internal to the interpreter
and dies at the application level. If the interpreter generates a SEGV
then we are pretty much stuffed anyway. However, it should be possible
to handle an application-level die without resorting to returning flags
all over the place. If the application dies a die, couldn't processing
the die be deferred until the current operation has completed and
control passes back to the main loop of the interpreter?
> >>By cancellation
> >>point I mean somewhere that is defined as 'safe', i.e. not holding any
> >>mutexes or waiting on any CVs etc.
>
> So what do we do if we die with a lock held?
I'm specifically talking about interpreter-level consistency rather than
trying to figure out what the application is doing. If the app hangs
because of a deadlock in the user's code - tough, that's their problem.
Don't forget that if you are using POSIX threads for example, only the
thread that has the mutex locked is allowed to unlock it, so even if the
interpreter *was* able to detect what application-level mutexes needed
to be unlocked to restore the app to a sane state, it couldn't
necessarily do so anyway. Throw into the mix the fact that each thread
will be running a separate interpreter instance and the whole thing
becomes nightmarish.
Alan Burlison
Thread Previous
|
Thread Next