On Fri, 17 Aug 2012, Henning Thielemann wrote:
On Fri, 17 Aug 2012, Henning Thielemann wrote:
The doc of base-4.5:Foreign.ForeignPtr.addForeignPtrFinalizer states:
This function adds a finalizer to the given foreign object. The
finalizer will run before all other finalizers for the same
No. 1 question: do you have a reproduceable test case of both behaviors?
Edward
Excerpts from Henning Thielemann's message of Fri Aug 17 08:10:02 -0400 2012:
The doc of base-4.5:Foreign.ForeignPtr.addForeignPtrFinalizer states:
This function adds a finalizer to the given foreign object.
Did we ever sort out the original subject of this thread which was:
Should finalizers on a given foreign pointer be executed in the
order they were added?
It is obvious what addForeignPtrFinalizer can be used for if this
guarantee is made. As far as I can recall, no-one has suggested what
I think that should be the reverse order. For example, if you add a
finalizer to the result of mallocForeignPtr, you want it to run
before the thing is freed. (That's what Hugs does now.)
Sorry, yes, of course.
--
Alastair
___
FFI mailing list
To be honest, I don't understand why you are so opposed to this.
I don't want to encourage people to write code which can't work on
Hugs and NHC. If we provide Haskell finalizers with the restriction
that they can only call C code, users will go ahead and write
finalizers which call arbitrary
You do have to worry about the impact of running Haskell finalizers
at any point during execution of Haskell code. Since you can't do
any concurrency synchronisation between the finalizer and the main
Haskell thread, shared access to mutable data is impossible. This
is just something
I have to say that, given Simon's patch, I am inclined to revert
back to the old API for foreign pointers.
I don't think such a change should be made unless Malcolm and I are
able to implement it.
I'm not yet convinced that Simon's patch is as easy or correct as it
seems and will not be
Alastair Reid [EMAIL PROTECTED] wrote,
I have to say that, given Simon's patch, I am inclined to revert
back to the old API for foreign pointers.
I don't think such a change should be made unless Malcolm and I are
able to implement it.
I'm not yet convinced that Simon's patch is
PS: Is everybody going to be at PLI'02? Then, we could
discuss this face to face.
Manuel
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
Then I'll reformulate my question as a patch. [...]
Is there anything fundamentally wrong with this approach?
I still maintain that getting this to work, testing it and,
especially, maintaining it is a lot of work. [For example, you
mention that finalizers that point to the object they
Then I'll reformulate my question as a patch. [...]
Is there anything fundamentally wrong with this approach?
I still maintain that getting this to work, testing it and,
especially, maintaining it is a lot of work.
Isn't it worth a little effort? Requiring finalizers to be foreign
Actually in the current implementation the finalizers are not
attached to the ForeignPtr at all: it's the other way around.
Ah, I see.
Fortunately, I don't think my sketched implementation depended on such
an attachment since it added an attachment of its own. The design is
intended
On Thu, Sep 26, 2002 at 09:56:20AM +0100, Simon Marlow wrote:
Yes, you're right. We could do it that way. I'm also concerned about
adding the extra overhead though, especially if this is something that
will rarely be needed. Are we sure this is what we want?
It would
- make
Still hoping ;-) The discussion seemed to stop without reaching a
conclusion last time.
I thought it was concluded and the report changed such that all three
compilers which implement the ffi spec can implement it without
receiving a heart, lung and liver transplant.
At least, I still don't
On Wed, Sep 25, 2002 at 06:18:35AM +0100, Alastair Reid wrote:
Consider regcomp in Test.Regex.Posix.
I didn't find this example at all convincing because the existing
finalizer was written as a monolithic whole and this is a simpler,
clearer way to write the finalizer.
If the libraries
On Wed, Sep 25, 2002 at 09:33:04AM +0100, Ross Paterson wrote:
If the struct were allocated with mallocForeignPtr, you need another
C call to use as the finalizer for that, say hs_f_free().
Sorry, that's wrong: If the struct were allocated with mallocForeignPtr,
you're stuck. You've no choice
On Wed, Sep 25, 2002 at 10:25:31AM +0100, Simon Marlow wrote:
If the struct was allocated with mallocForeignPtr,
you're stuck. You've no choice but to use addForeignPtrFinalizer,
except that you can't because the order of finalizers is unspecified.
I can guarantee in GHC that if you add
I tell you what, I'll implement finalizer ordering if you
guys implement
full Haskell finalizers :-)
How about providing newForeignPtr as specified? (Or are you
still hoping?)
Still hoping ;-) The discussion seemed to stop without reaching a
conclusion last time. At least, I still
The spec says there are no guarantees on the order in which
the finalizers
are run. Doesn't this make this function almost impossible to use?
Suppose one finalizer frees the storage and the other cleans
up something
it refers to. I'd suggest running the finalizers in the reverse order
Alastair wrote:
I seem to remember that Sigbjorn and Erik dealt with this problem by
arranging some kind of GC-visible link between the objects so that
until the second finalizer has run, the object will not be
considered garbage.
Sorry, this was nonsense - I hadn't noticed that is was a
20 matches
Mail list logo
