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?
Yep, we need the interpreter as argument.
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.
We could put this list into the interpreter structure itself, so that created interpreters would be chained together. Actually, the <runinterp> ops used in t/op/interp_2 runs the code of the parent interpreter for execution, so there might always be some kind of reusal of structures, which chained interpreters have to know in _destroy.
Same is with my experiment of a separate interpreter for the tracing subsystem (currently disabled, s. runops_cores.c).
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 ;-)
Would be greate, thanks.
--Josh
leo
