Re: [hoc-devel] withAutoreleasePool in finalizers

[Wolfgang T. <wol...@gm...>]

First of all, it's great to see this list really coming to life :-).

On Aug 25, 2008, at 5:29 PM, Gustav Munkby wrote:

> I do not understand why this works, but
> this _is_ in the "Arcane Magic" section
> of HOC, so I guess I should not be too
> surprised. =)
>

I think the original problem is that there was not necessarily an  
autorelease pool available for use by an object's dealloc method, so  
wrapping the calls to dealloc and release should be the right thing to  
do.

> Is this the right way to fix this problem?

I think it's *almost* the right way.
More importantly, in this case, I think that the autorelease pools  
have to be created and destroyed in HOC_cbits/MemoryManagement.m  
rather than on the Haskell side.
I still have to double-check this, but I seem to remember that GHC  
finalisers are run as lightweight threads by GHC, which means that we  
get no guarantee on which of the GHC runtime system's worker OS  
threads gets to execute each timeslice of the finaliser; it is  
therefore theoretically possible that the pool gets installed in one  
OS thread, but the actual dealloc executes in another, and the pool  
dealloc in yet another OS thread (which might have a *different* pool  
in place, causing lots of confusion). Not likely, but I am kind of  
afraid of it.

> I tried wrapping the finalizers in
> withAutoreleasePool which removed the
> messages, but resulted in Yi crashing after
> some time when an autoreleasepool is
> deallocated twice. I can reproduce the
> error, but not predictably.

I think your attempt of wrapping the entire finaliser might have  
caused the time window for this problem to be longer, and therefore  
just made the crashes more likely than if you just wrap the actual  
dealloc. So we'll probably have to do it the hard way (we can't use  
*real* objective C if we want to be able to use GHCi, so we have to  
send all the messages "by hand" from C).

Cheers,

Wolfgang