#1364: Finalizers not guaranteed to run before the program exits
----------------------------------+-----------------------------------------
Reporter: [EMAIL PROTECTED] | Owner: simonmar
Type: feature request | Status: new
Priority: normal | Milestone: 6.10.1
Component: Runtime System | Version: 6.6.1
Severity: normal | Resolution:
Keywords: | Difficulty: Moderate (1 day)
Testcase: | Architecture: Unknown
Os: Unknown |
----------------------------------+-----------------------------------------
Comment (by Svarog):
Replying to [comment:12 simonmar]:
I've just uploaded updated patches for the base lib, the testsuite and ghc
to address these issues.
The new ghc patch just adds a comment in Weak.c to mention that finalizers
rely on weak pointers
in weak_ptr_list always being in the same order (which is currently the
case).
> * we shouldn't be extending the `Foreign.ForeignPtr` API, as it is set
in stone
> by the FFI spec and would need at the very least a library proposal
to
> change it. I had imagined that we would keep the same API, and just
implement C
> finalizers differently.
>
As discussed on IRC, addForeignPtrFinalizer only needs to work with C
functions so I renamed addForeignPtrFinalizerC to addForeignPtrFinalizer.
That way the API stays the same.
To use Haskell finalizers addForeignPtrConcFinalizer should be used.
> * The implementation doesn't seem to respect the ordering of
finalizers.
> Finalizers are supposed to run in the same order that they were added
to the
> `ForeignPtr` (which is why we have that horrible `IORef` attached to
> `ForeignPtr`s). It looks like C finalizers will run in an arbitrary
order.
>
Weak pointers are always kept in the same order and each C finalizer is
attached to its own weak pointer. All C finalizers attached to a
particular `ForeignPtr` should execute in correct order. I've updated one
of the tests in the testsuite to check for this.
As discussed on IRC I added code that throws a run-time error if Haskell
and C finalizers are mixed on the same `ForeignPtr`. I've added another
test to the testsuite to check this as well.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1364#comment:13>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
