Manuel M T Chakravarty [EMAIL PROTECTED] wrote,
We seem to have a consensus on this one. We change the type
of the existing functions to
newForeignPtr :: Ptr a - FunPtr (Ptr a - IO ()) - IO (ForeignPtr a)
addForeignPtrFinalizer :: ForeignPtr a - FunPtr (Ptr a - IO ()) - IO ()
For
The FFI Addendum actually doesn't commit to which operations
are in the class. It just says defines all these ops to
have a context `Bits a', which is definitely the case. In
other words, you proposed implementation is valid by the
spec and your argument for it makes sense to me.
The
Manuel M T Chakravarty [EMAIL PROTECTED] writes:
So, I would propose to
change the FFI spec. The main reason being that there is
already plenty of code which relies on the current
definition in GHC's Bits and there is no good reason to
break that code. Objections?
That's fine with me.
I think the thing to do is add the existing performGC to the standard
(perhaps giving it an hs_ prefix in the process) and leave development
of an extended version of the function for when the GHC folk (or
anyone else with a generational collector) decide they want a
forcefulness argument. Come
Errm, but in C there is no unified shift operator. You have for
left shift and and for right shift, and a negative shift is
undefined.
[blush]
This makes the specification come out nice and clean - you're
multiplying the number by 2^n instead of 2^{-n}.
Errm, but then right shift
Alastair Reid [EMAIL PROTECTED] writes:
So, my proposal is to:
[...]
I think only GHC implements anything like this (correct me if wrong,
Malcolm) and they haven't used it in the way John Meacham is
interested in.
At the moment, nhc98 provides a routine
void haskellInit (int argc,
Manuel wrote (snipped)
I have changed this in the spec now. I attach the wording
used in the spec.
\item[newForeignPtr ::\ Ptr a - FunPtr (Ptr a - IO ()) - IO (ForeignPtr a)]
Turn a plain memory reference into a foreign object by associating a
finalizer with the reference. The
I think this is all a rather murky area. Consider two systems,
let's call them Haskell and Foogle, which both operate heaps and do
their own storage allocation, but also communicate over similar
FFIs.
This is indeed a murky area.
Especially tricky when you have two GC's (even if one is
Malcolm Wallace wrote
[snip]
I don't see the problem. The Foogle garbage collector runs separately
and asynchronously to the Haskell GC. A Foogle object is released
by the Haskell collector, then at a later moment in time, a Haskell
object is released by the Foogle collector. Where is the
Alastair Reid wrote
[snip]
We should provide a C function hs_freeStablePtr and explicitly
say that it is safe to call this from inside a finalizer.
[snip]
This would be the simplest solution, but would not permit you to do
anything more sophisticated at the Haskell side, such as reference
Malcolm Wallace wrote
[snip]
Quite simply, no finaliser (whether in Foogle or Haskell) should
be capable of triggering a garbage collection within its call.
This condition is absolutely necessary to prevent a cascade effect
of cross-language garbage collections, where a finaliser in Haskell
George Russell [EMAIL PROTECTED] writes:
Unfortunately some sort of cascade is exactly what we want and need when
the Haskell finaliser indicates that Haskell is no longer interested in
some Foogle object, which means Foogle can run a GC which indicates
Foogle is no longer interested in some
[snip] No, you do not really need separate threads for this problem
to occur. All you need is, say, Hugs to call a GHC-exported
function as a finalizer, in the same OS thread, GHC to run a garbage
collection during this function, and the garbage collection in turn
to want to run a Hugs
13 matches
Mail list logo
