Simon Marlow [EMAIL PROTECTED] writes:
Ok, I'm sad to say that the problem we recently uncovered to do with
finalizers sharing values with the rest of the program essentially kills
off the possibility of doing Haskell finalizers in systems without
proper concurrency support.
Well, I'm not
Ok, I'm sad to say that the problem we recently uncovered to do with
finalizers sharing values with the rest of the program essentially kills
off the possibility of doing Haskell finalizers in systems without
proper concurrency support. I'm rather embarassed that I didn't notice
this before;
Hi,
I have only been watching this Haskell finalizers discussion from a
great distance, but I am keenly interested in the outcome, as it will
require a significant overhaul of some of my own FFI-based library code.
(My code currently uses touchForeignPtr in a Haskell finalizer to
express a
[snip] How sad. It's an unfortunate hole in the specification and I
hope someone will come up with a way of fixing it someday.
I don't think it'll happen until preemptive concurrency is more widely
implemented.
In the meantime, I'm glad we have got a new function
atomicModifyIORef which I
The problem is that the G-machine optimizes away some of the
updates which make sure that the heap is always in a consistent
state in a pure graph-reduction system.
A pure G-machine updates all redexes, but the STG-machine only
updates /shared/ redexes, yes?
It's a while since I looked at
I also need the touchForeignPtr trick in much of my code. we need to
come up with a replacement if we dont have haskell finalizers. here are
my canidate suggestions:
* add a subset of Weak pointers (or some subset of their functionality)
to the FFI spec. just get rid of the finalizer capability
