On 30 November 2004 16:39, Benjamin Franksen wrote:

[re-sending because I got no response yet]

On Tuesday 23 November 2004 13:06, Simon Marlow wrote:

...

On 22 November 2004 17:28, Benjamin Franksen wrote:

...

However, what I don't understand is why touchForeignPtr is not honored in my example program: Note that the output text lines from the finalizers appear *before* the last action in the program (which is a second getChar). The finalizers *are* called by the GC, and still the order is wrong.

Note that the GC only starts the finaliser thread. The program can still terminate before this thread has run to completion

I repeat: the program is not yet even near termination when the finalizers get executed (in teh wrng order).

Here is the example program again (with 3 lines added to the end of main to illustrate the point):

import Foreign hiding (newForeignPtr) import Foreign.Concurrent import System.Mem (performGC)

type A = ForeignPtr Int

type B = ForeignPtr Bool

newA :: IO A newA = do (pa::Ptr Int) <- malloc newForeignPtr pa $ do putStrLn "before finalizing A" free pa putStrLn "after finalizing A"

newB :: A -> IO B newB fpa = withForeignPtr fpa $ \pa -> do (pb::Ptr Bool) <- malloc newForeignPtr pb $ do putStrLn "before finalizing B" free pb putStrLn "after finalizing B" touchForeignPtr fpa

main = do a <- newA b <- newB a getChar performGC getChar putStrLn "Program still not terminated, please hit <enter> again!" getChar putStrLn "Program termination will now be initiated."

And this is the output:

franksen@linux: .../foreigntouchbug > ./a.out <enter> before finalizing A after finalizing A before finalizing B after finalizing B <enter> Program still not terminated, please hit <enter> again! <enter> Program termination will now be initiated.

The GC simply found that both objects were unreferenced and hence ran their finalizers, in no particular order. The fact that B referred to A has no effect, since both objects were unreachable from the roots. If B had been reachable, then A would not have been finalized - this is the only way in which the ordering would have shown up. This is just a manifestation of the lack of ordering between finalizers - sorry if I wasn't clear before. The documentation will be updated for the 6.4 release to more closely reflect the state of affairs. Cheers, Simon