perl 5.8 and malloc (and mod_perl)

[Mike Harding]

Short answer - signals have changed for 5.8+, they added "Safe signals"
that let you do anything in a signal handler, but this handlers will
only be run between Perl byte codes.  The old 'unsafe' behavior is
available via a switch if you can't handle the latency or rely on the
old (unreliable) behavior.  See perlipc(1), search for "Deferred
Signals".

- Mike H.

On Fri, 2004-01-16 at 04:54, Alexander Leidinger wrote:
> On Fri, 16 Jan 2004 15:27:50 +0300
> Sergey Matveychuk <sem at ciam.ru> wrote:
> 
> > Alexander Leidinger wrote:
> > > I don't know if the situation changed with perl 5.8, but with 5.6 you
> > > have to compile with perls malloc if your application makes use of
> > 
> >  From lang/perl5.8/Makefile:
> > .if defined(WITHOUT_PERL_MALLOC)
> > .undef WITH_PERL_MALLOC
> > .else
> > WITH_PERL_MALLOC=       yes
> > .endif
> > 
> > WITH_PERL_MALLOC is default.
> 
> Yes, I know. I was referring to the implementation of signal handlers in
> perl, not to being perl malloc the default in our perl 5.8 or not. I
> don't think this situation has changed, as I can't think of an
> implementation which gets it right without disallowing certain perl
> language constructs in signal handlers, but I there are people out there
> which are smarter than I am, and I don't want to limit their creativity
> by saying it's not possible...
> 
> Just a little note: what if a perl application makes use of signal
> handlers and at the same time needs a perl without perl malloc...
> 
> Bye,
> Alexander.