Re: [hoc-devel] withAutoreleasePool in finalizers

[Gustav M. <grd...@gm...>]

>> 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.

If this is the case, it would explain the behavior that I'm seeing, but
with my limited understanding of how the GHC internals work, there
could be a lot of other plausible explanations as well. =)

>> 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).

Actually, that does not seem to be a major problem, since we can
just reuse the functions already declared in MemoryManagement.h.
See the attached patch for a first go at this.

!g