At 8:02 on 11/08/2002 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Josh Wilmes wrote:
>
> > For the meantime, I have added the Parrot_exit and Parrot_on_exit function
s
> > to CVS.
>
> Thanks for providing this. I did slightly modify your patch to really
> get rid of the leaks:
> - test
Josh Wilmes wrote:
For the meantime, I have added the Parrot_exit and Parrot_on_exit functions
to CVS.
Thanks for providing this. I did slightly modify your patch to really
get rid of the leaks:
- test_main calls Parrot_exit now
- copied prototype to embed.h
leo
For the meantime, I have added the Parrot_exit and Parrot_on_exit functions
to CVS.
This will fix the leak on all platforms, for now. If you want to fix
internal_exception so this isn't necessary, that's fine- we can rip this
out later.
--Josh
At 22:21 on 11/06/2002 +0100, Leopold Toetsch <
At 15:57 on 11/06/2002 EST, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >This is was I did say above, just put comments around above
> >statement if tinderboxen are the concern.
>
> Yeah, I think I'll do that for right now. What I'd like is a probe
> for this in configure. Oh, Brent :)
If an
Dan Sugalski wrote:
- I implemented Parrot_destroy, which cleans up all internal data
structures of an interpreter and frees all used mem.
Right, I understand. (And I really appreciate it--this was a hanging
area that didn't get nearly the proper attention it needed) The bit I
don't underst
At 9:19 PM +0100 11/6/02, Leopold Toetsch wrote:
Summary of changes I did put in WRT this:
- interpreter startup code is reordered so that all PMCs/Buffers are
in managed memory now.
- Long running programs using e.g. new interpreters on the fly would
currently leak tons of memory.
- Debugging m
Dan Sugalski wrote:
At 1:47 PM -0500 11/6/02, Josh Wilmes wrote:
At 13:41 on 11/06/2002 EST, Dan Sugalski <[EMAIL PROTECTED]> wrote:
Well, I got bit this week by the on_exit stuff. I'm still not sure
why we need this. Could someone please explain, so I don't have to
yank it out?
Leo sai
At 13:55 on 11/06/2002 EST, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >Leo said:
> >
> >> The on_exit/atexit is currently necessary to clean up behind exceptions.
> >> If you don't mind memory leaks after exceptions, remove the
>
> Right, I saw that, I just don't understand why. If it's in as a
At 1:47 PM -0500 11/6/02, Josh Wilmes wrote:
At 13:41 on 11/06/2002 EST, Dan Sugalski <[EMAIL PROTECTED]> wrote:
Well, I got bit this week by the on_exit stuff. I'm still not sure
why we need this. Could someone please explain, so I don't have to
yank it out?
Leo said:
The on_exit/atexit
At 13:41 on 11/06/2002 EST, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Well, I got bit this week by the on_exit stuff. I'm still not sure
> why we need this. Could someone please explain, so I don't have to
> yank it out?
Leo said:
> The on_exit/atexit is currently necessary to clean up behind
At 1:31 PM -0500 11/6/02, Josh Wilmes wrote:
At 7:58 on 11/06/2002 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
Josh Wilmes wrote:
> I agree. However, the point is fairly moot.. If we're going to do a
> Parrot_on_exit, it's just as easy to provide our own Parrot_exit and not
> need
At 7:58 on 11/06/2002 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Josh Wilmes wrote:
>
>
> > I agree. However, the point is fairly moot.. If we're going to do a
> > Parrot_on_exit, it's just as easy to provide our own Parrot_exit and not
> > need atexit() either.. it's not like atex
Josh Wilmes wrote:
I agree. However, the point is fairly moot.. If we're going to do a
Parrot_on_exit, it's just as easy to provide our own Parrot_exit and not
need atexit() either.. it's not like atexit() is giving us much at that
point.
which would mean, that internal_exception ne
At 21:09 on 11/05/2002 GMT, Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 04, 2002 at 07:45:46PM -0500, Josh Wilmes wrote:
> > 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
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
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 func
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 cou
Andy Dougherty (via RT) wrote:
That's because Solaris doesn't have on_exit. It does have atexit, but
atexit doesn't take any parameters so it's not a direct drop-in
replacement. The correct "fix" is not obvious to me. I suppose
someone could have Configure.pl test for on_exit and only use it
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #18219]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18219 >
The Solaris tinderbox is currently failing with
gcc -o parrot [...]
Undefined
19 matches
Mail list logo
