(message referred to follows)
Alastair suggested implementing blockFinalizers rather than PVars. However I
dislike this for two reason:
(1) I'm rather attached to PVars. Not just because I suggested them (actually
I think I stole them from Einar Karlsen) but because it looks to me as if they
Alastair Reid wrote:
[snip] I don't see that it's necessary for us to come to a decision
right now about PVars unless we want to put them in the FFI
standard.
But what if we can't agree on something like PVars or we decide that
Haskell finalizers plus yet another synchronization
On 16-Oct-2002, Antony Courtney [EMAIL PROTECTED] wrote:
Does anyone know off hand:
- Is it a safe, portable assumption that enums will always be
encoded as an unsigned short or 16-bit word?
No, that assumption is not safe or portable.
- If not, then how should enum values be
The document which Simon and Alastair have kindly put together asks for more details
about why I want foreign garbage collectors to be able to call back to Haskell. Well
I can't supply many details, because this is not immediately required by the
UniForM/MMiSS
project we are working on at
I like what Simon and Alastair have written in the finalizers document. However
I don't think there is any proposal I can wholeheartedly support, so I have to produce
my own, which is a mixture of almost all the proposals (1)-(5). I hope though that
this proposal will at least provide a
George writes:
If you have Haskell talking to some
other language with a garbage collector, be it Java or SML, then at
a given point of the program you can in general expect to have
Haskell holding stable pointers to objects referenced from their
world by the other language, and vice-versa.
Alastair Reid wrote:
George writes:
If you have Haskell talking to some
other language with a garbage collector, be it Java or SML, then at
a given point of the program you can in general expect to have
Haskell holding stable pointers to objects referenced from their
world by the
(2) blockFinalizers looks fine for Hugs and NHC which only have a
single-thread model, but it looks tricky in general where [...]
Ah, I see what you mean.
I'd kinda hardwired into the definition the assumption that finalizers
run at higher priority than other threads and that there's a
So what you want is for the Java GC to call hs_freeStablePtr on all
the Haskell objects that just died?
No, that's only a partial (and indeed very incomplete) solution. It
relies on the Java GC knowing that that particular reference to the
Haskell StablePtr is the only one that matters,
it was less an argument either way and more of a statement of
consequence as to what disallowing Haskell finalizers would cause. The
problem can best be summed up by this snippet of the current FFI spec.
excerpt from FFI:
touchForeignPtr :: ForeignPtr a - IO () Ensure that the
SimonM:
[...] Can we easily identify which are the unsafe places and fix them?
Alastair:
Look at all prims with types in IO. Look at what data structures they
touch. Check if there are accesses to that data structure 'both
sides' of a call to eval (there may be a few functions which invoke
11 matches
Mail list logo
