FW: Re: sigint, memoize

MJD sent this message a few months ago.  I meant to try and write
something up, but after three months, it's fallen off the bottom of my
todo list.

Anyone want to patch the faq?

-R


=== Forwarded Message:

To: Walter Roberson <[email protected]>
Subject: Re: sigint, memoize 
Cc: [email protected]
Date: Wed, 11 Feb 2004 07:16:26 -0500
From: Mark Jason Dominus <[email protected]>


>   I noticed that at one point in the documentation, you suggest,
> 
>         $SIG{INT} = sub { unmemoize 'function' };
> 
> Perlfaq8 indicates,
> 
>           Unless you're exceedingly careful, the only safe things to
>           do inside a signal handler are (1) set a variable and (2)
>           exit.  In the first case, you should only set a variable in
>           such a way that malloc() is not called (eg, by setting a
>           variable that already has a value).

This was never correct.  

The only things you can do inside of a signal handler in the C
language are set a variable (of type 'volatile sig_atomic_t') and
exit.  (Actually, there are a couple of other things; you are allowed
to reset the signal handler for the signal that just occurred, for
example; you are allowed to call 'abort', and probably a couple of
others.)

The way Perl signal handlers used to work was that Perl itself would
have signal handlers in its C code that would catch the signal, then
check the %SIG array, and then call your Perl function.  When the Perl
function returned, so too would the C signal handler.  Regardless of
what your Perl function did, this was already violating the
restrictions on what a C signal handler could do.  Even if the Perl
function did nothing but set a Perl variable, this might well end up
calling 'malloc' internally, and calling 'malloc' is definitely one of
the things you are *not* allowed to do while a signal handler is
executing.  Perl could, and did, dump core even if you followed the
instructions in perlfaq8.

In Perl 5.8.0 or 5.8.1 (I forget which), Perl's signal handler
mechanism was completely reworked so that Perl obeyed the restrictions
on what signal handlers were allowed to do.  It would no longer call
the %SIG function directly out of the C signal handler.  Instead, the
C signal handler would set a flag (of type volatile sig_atomic_t, as
required) and return immediately.  Later on, Perl would check for the
flag, and if it was set, Perl would call the appropriate %SIG
function.  In these versions of Perl, it's perfectly safe to do
whatever you want inside of the %SIG function.

> Is 'unmemoize' "exceedingly careful" ?

No, but the FAQ is wrong, so it doesn't matter.  In old versions of
Perl, *nothing* is 'exceedingly careful', and your program might fail
and dump core regardless of whether you call 'unmemoize' inside the
function; in newer versions of Perl you can do whatever you want, so
it doesn't matter either way.

> Looking over the Memoize code, I see that the caches are not shared
> amongst threads. I should experiment and see if I can get shared
> behaviour by providing a shared cache variable.

I would expect so, but I will be interested to hear about your
results.

Thanks very much for your interest.  I am cc'ing the current
maintainers of the perlfaq so that they can correct this erroneous
section of the manual.

=== End of Forwarded Message