On Mon, Nov 04, 2002 at 07:45:46PM -0500, Josh Wilmes wrote: > At 18:57 on 11/04/2002 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote: > > > atexit is not an alternative, because we might have multiple > > interpreters to clean up like in t/op/interp_2. > > So the issue here is that on_exit can take a parameter to be passed into > the handler function, right? > > We could implement our own version of on_exit that registered the handlers/ > arguments in a linked list or something, and have a single atexit() handler > call them on our behalf. > > However, that still assumes we have atexit() everywhere. This appears to > not be true on SunOS at least- apparently it has on_exit, though.
IIRC ANSI C89 says that the library provides atexit() If SunOS doesn't want to be C89 compliant, then I have no qualms about telling the first SunOS porter that we'd be pleased to accept patches from *them* to work around it. (And the return value from sprintf in SunOS, if we need that.) > But, it seems like we can make this work everywhere if we move to using a > platform.c Parrot_on_exit() and Parrot_exit() rather than any kind of > native on_exit/atexit/exit functions. That seems to be a better plan. > Then we can make them all DTRT everywhere, I think... either with our > without atexit(). > > If this (Parrot_exit/Parrot_on_exit) is a reasonable way to do things, I > can probably come up with a patch later this week, if nobody else jumps on > it ;-) I'm not jumping. Sorry. Nicholas Clark PS Yes, I may sound beligerant and unhelpful. But implementors have had >12 years to get C89 correct. C99 is more complex - I wonder how long long that will take... -- Slide rules better than perl? http://www.perl.org/advocacy/spoofathon/
