John
I'm not quite sure what you mean. I think you are saying that this is a
reason it's important to have Haskell finalizers, but I'm not sure. How
would you like to write a paragraph or two to explain the issue, and we
can put it in the document? That way it would say what you mean.
Simon
Hi Alastair
| a comment on SimonM's finalizer document. I decided to comment rather
| than edit since my comments require more than tweaking the odd word
| here and there.
I suggest you edit directly, striving, as Simon did, to be even-handed.
I do have one comment on your rejoinders, though:
When it comes down to it, I don't think we are that far apart.
1. Everyone wants a C-finaliser interface; it's very convenient. So it
should be in the spec. It's probably a good plan to specify that such C
finalisers must obey the constraints of an 'unsafe' foreign import.
2. It is clear tha
> If you have a concurrent Haskell program, with
> mutable state and MVars and all, it's entirely likely that you'll
> have mutable state that reflects the state of the external (e.g. C)
> world. For example, the GHC I/O library has Haskell I/O handles
> that reflect the state of the underlying
I would be much happier with Simon's compromise than with Manuel's.
--
Alastair
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
> Things you mights add are:
>
> eg(1) in composite finalizers:
>
> This would be handled just fine by C finalizers if
> addForeignPtrFinalizer guaranteed to execute finalizers in reverse
> order of their addition. This seems like a reasonable thing to
> specify since addForeignPtrFina
> I dont have cvs write access but you should mention something about
> expressing gc dependencies between ForeignPtr's. the only two
> ways to do
> this in the current haskell systems are
> * weak pointers
> * touchForeignPtr from the finalizer of another ForeignPtr
Actually I have a feeling th
> > Indeed, I very nearly implemented such a thing as part of the patch
> > I sent out. However, it didn't look trivial enough to implement so
> > I backed off. The "blocked" state needs to be saved & restored at
> > various points: when starting a finalizer, when invoking a
> > foreign-exported
> Does this run into problems with exceptions?
Good question.
I think the answer depends on what happens if a Haskell finalizer
raises an IOError, calls System.exit or (Hugs/GHC extension) raises an
Exception. I don't think the ffi spec comments on these. I'd guess
the answer is:
1) Returnin
> > Also, this is a nested call to eval(), in a primitive, which can
> > invoke an IO action and therefore re-enter Haskell without going
> > through unsafePerformIO. Is that safe?
>
> Yes, I think so. Most calls to IO actions from primitives are safe
> and I believe these ones are too. (In so
> So, are we now claiming that my patch *is* safe? (Never mind about
> IORefs, I'm talking about the implementation itself).
No.
And my recent focus on IORefs has simply been because they seemed the
strongest argument.
A
___
FFI mailing list
[EMAIL
> > So, are we now claiming that my patch *is* safe? (Never mind about
> > IORefs, I'm talking about the implementation itself).
>
> No.
Then I'm confused. Allow me to quote your previous message:
> Most calls to IO actions from primitives are safe
> and I believe these ones are too.
So i
>> > So, are we now claiming that my patch *is* safe? (Never mind
>> > about IORefs, I'm talking about the implementation itself).
>>
>> No.
> Then I'm confused. Allow me to quote your previous message:
>> Most calls to IO actions from primitives are safe and I believe
>> these ones are too.
13 matches
Mail list logo
