At 04:02 PM 3/28/00 -0500, [EMAIL PROTECTED] wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
> > At 01:37 PM 3/28/00 -0600, Craig A. Berry wrote:
> >>At 01:52 PM 3/28/00 -0500, Charles Lane wrote:
> >>
> >> >+ I'm using LIB$(GET|FREE)_VM here so that we can allocate and
> deallocate
> >> >+ inside an AST routine without worrying about reentrancy and
> which Perl
> >> >+ memory allocator is being used.
> >>
> >>Mixing these with malloc() used to be a no-no; does the fact that you have
> >>them in an AST routine allow you to dodge that restriction?
> >
> > Should we just switch over to the LIB$ memory management stuff altogether?
> > It'd just require some changes to perl's memory allocator.
>
>Well, it *is* amusing to see the discussion on P5P about how you can't
>even malloc inside a signal handling routine without risking a crash.
>I've used malloc inside AST handlers with no problem, and LIB$ stuff is
>robust. Makes you appreciate VMS all the more :-)
It's probably why we have so few problems on VMS. There's still a lot you
can't do at AST time, but it's a lot safer than on Unix. (Signals aren't
any more safe for us, but who uses 'em anyway? Bleah)
At some point I plan on implementing the equivalent of ASTs in perl. Might
even be able to execute real perl code at AST time rather than deferring
it, though that'll be a touch tricky. (How just hit me, courtesy of
Sarathy's IThreads implementation...)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
