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 object which have already been registered."

I do

addForeignPtrFinalizer finalize1 fp addForeignPtrFinalizer finalize2 fp

and let the finalizers print something when they are started. I get the output:

finalizer1 finalizer2

This indicates that the newly added finalizer is run _after_ the finalizers that are already registered. Is this a documentation bug or a bug in the base library?

Hm, it seems to depend on the context. In some situations I get the correct (reversed) order

finalizer2 finalizer1

and in others I get finalizer1 first and then finalizer2. Any hint what can change the order of finalizers?

continuing my monologue ... It seems that a simple modification like turning a not directly related allocaBytes into a mallocBytes reverses the order from incorrect to correct (reversed). Maybe adding the finalizers is not the problem but running them. Maybe there are different ways to run the finalizers and allocaBytes causes an invalid execution of finalizers whereas mallocBytes leaves the correct way.

On Fri, 17 Aug 2012, Edward Z. Yang wrote:

No. 1 question: do you have a reproduceable test case of both behaviors?

Unfortunately I was not able to reduce it to a small test. Below a certain complexity the problem vanishes. Currently my example has many dependencies on external libraries (libav etc.) :-( Thus I hoped I could approach the problem from a different direction. If there are different ways to run the finalizers of a ForeignPtr then I could check them. I could not find something suspicious in base:GHC.ForeignPtr, though.