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

[Tom Christiansen <tchrist@jhereg.perl.com>]

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

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.'')?

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?

Is sleep() a sys-related case?

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

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.

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.  

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

--tom

---

Follow-Ups from:

Tom Horsley <Tom.Horsley@mail.ccur.com>
Dan Sugalski <dan@sidhe.org>
Larry Wall <larry@wall.org>

References to:

Larry Wall <larry@wall.org>

---

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

---