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

[Larry Wall <larry@wall.org>]

Tom Christiansen writes:
: On Mon, 10 Jan 2000 13:28:16 -0800 (PST)
:     Larry Wall <larry@wall.org> wrote
:     in <200001102128.NAA15919@kiev.wall.org>:
: 
: :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.
: 
: What about slow-running ops?  It seems like some of them require more
: careful work than others.  For example, sort() on a large data set can
: take a swell spell, and readline() on a serial line or stream connection
: can take virtually infinite time.  In the latter case, I suppose we have
: the EINTR and the SA_RESTART dodge.  Here's my list of such operators:
: 
:     sys related:    accept, close, connect, fcntl, flock, getc, ioctl,
: 		    open, print, read, readline, recv, send, syscall,
: 		    sysread, syswrite, wait, waitpid
: 
: Those aren't that bad.  It's the others that seem more challenging.
: For example:
: 
:     indirect calls: sort, map, grep

That's why I said, "at the iterator [un-sic] of any looping constructs."
I was counting those as looping constructs.

: Where do those take the signal?  What if it's a built-in sorting, such as
: C<sort @array>, or using the newly optimized built-ins (from perldelta:
: ``Simple sort() using { $a <=> $b } and the like are optimized Many
: common sort() operations using a simple inlined block are now optimized
: for faster performance.'')?

The proper check point is probably in qsortsv(), which is used to call all
the other routines.

: What about system() and `backticks`?  Are these part of the sys-related
: case above?  Is glob() an issue?  It uses many readdir()s, unless it's not
: built-in, in which case it will be using an external program.  Does this
: fall into the system() and `backtick` case?

Any op of that sort can set a flag which says it's safe to call the sub
directly, as we do now.

: Is sleep() a sys-related case?

Can be solved with either as above or via EINTR.

: What about list-context flipflops?  "a" .. "zzzzz" takes a long time
: (well, until you hit out of memory :-).

"at the iterator of any looping constructs"

: How about the dofile and require operators?  Is it safe to permit
: receipt of the signal once they've compiled and once they're executing
: their newly compiled code?  I assume that the import() component of
: the use operator would be signallable during its execution.

The iterator of the compiler is byacc.

: Finally, let's have some fun ones.  What about tie() and its related
: intercepts?  There's no reason to imagine that any of the TIE*() functions
: shall complete in "reasonable" (non-arbitrary) time.  At what granularity
: should they be interruptible?  Consider:
: 
:     tie %mib, 'Tie::SMTP', $remhost;
:     $desc = $mib{ "system.sysDescr" };
: 
: The tie itself might take a long time because $remhost is unreachable.
: If there's underlying Perl code that's stuck in one of the previously
: mentioned cases (e.g. connect), perhaps this suffices.  Same situation
: with the tied()d call to FETCH() in the next line.  

If it's tied to Perl code, that operates at the granularity of the Perl
code, as normal.  A connect would be an EINTR or "sig_sub_is_safe = 1"
situation.

: But what if it's in XS code?  How will reliable signal delivery interact
: with XS code?

Existing XS code is a problem regardless.  Inventing a new minilanguage
does not solve this.  We have the choice (or perhaps the user has the
choice) of whether frequent hanging or occasional core dumping is
the lesser of two evils.  But there are at least three ways to ameliorate
this.

First, we can do the deliver-immediately-on-duplicate-signal trick.
That could be generalized to deliver immediately on any second signal if
sufficient time has passed, provided time() is a safe system call.

Second, we could interrupt ourselves periodically with an interval timer
on systems that support that, and deliver any sufficiently delayed signals
immediately.

Third, we could document how to install a check point, deal with EINTR,
set sig_sub_is_safe, etc. for the benefit of XS writers, in the
expectation that they'll do the right thing.

As far as I'm concerned, the main remaining issue is how to direct
signals to a particular thread.  This seems to me to be an issue of
the check point code simply refusing to deliver a signal unless the
right thread is running (and of course making sure the signal thread
gets scheduled as soon as is reasonable).  We might not be able to
honor sig_sub_is_safe under threaded code, but then all your blocking
operations should send you back to the scheduler anyway, so it
doesn't seem to be a big issue.

In short, this is all insane, but it's the sort of insanity we should
be protecting the Perl programmer from. 

Larry

---

Follow-Ups from:

Tom Christiansen <tchrist@jhereg.perl.com>
Ilya Zakharevich <ilya@math.ohio-state.edu>

References to:

Tom Christiansen <tchrist@jhereg.perl.com>

---

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

---