On 26 July 2005 16:49, Einar Karttunen wrote:
Simon Marlow [EMAIL PROTECTED] writes:
No, unfortunately not. You have foo's finalizer which refers to bar
via a touchForeignPtr. If both foo and bar are unreachable
(references from finalizers don't count), then both foo and bar's
finalizers
On 25 July 2005 14:44, Einar Karttunen wrote:
What is the correct way to express liveness dependencies for
ForeignPtrs? I am wrapping a C library and need a way to keep
ForeignPtrs alive until the finalizer for an another ForeignPtr
has been executed.
Basically I have two types, ForeignPtr
Simon Marlow [EMAIL PROTECTED] writes:
You might be able to find more information on this in the mailing list
archives. It's true that touchForeignPtr isn't enough to enforce an
ordering on the running of finalizers, but it *can* be used to express a
liveness relationship between one
On 26 July 2005 11:26, Einar Karttunen wrote:
Simon Marlow [EMAIL PROTECTED] writes:
You might be able to find more information on this in the mailing
list archives. It's true that touchForeignPtr isn't enough to
enforce an ordering on the running of finalizers, but it *can* be
used to
On 26 July 2005 14:15, Einar Karttunen wrote:
Simon Marlow [EMAIL PROTECTED] writes:
Now the association becomes
associate (Foo _ ref) bar =
atomicModifyIORef ref (\lst - (touchForeignPtr bar : lst, ()))
Isn't that equivalent to using addForeignPtrFinalizer? I don't think
this fixes
Simon Marlow [EMAIL PROTECTED] writes:
No, unfortunately not. You have foo's finalizer which refers to bar via
a touchForeignPtr. If both foo and bar are unreachable (references from
finalizers don't count), then both foo and bar's finalizers will be
started together, and may run in any
Hello
What is the correct way to express liveness dependencies for
ForeignPtrs? I am wrapping a C library and need a way to keep
ForeignPtrs alive until the finalizer for an another ForeignPtr
has been executed.
Basically I have two types, ForeignPtr A and ForeignPtr B and a function
