Sending to the list as well. On Jun 19, 2011 9:58 AM, "Antoine Latter" wrote:

On Jun 19, 2011 7:49 AM, "Bas van Dijk" wrote:

...

On 19 June 2011 14:13, wren ng thornton wrote:

...

The documentation claims that the finalizers are run only once the ForeignPtr becomes unreachable,

which

...

...

implies that keeping the ForeignPtr is sufficient to keep the foreign object alive.

Right, that was also my thinking when designing the usb library. What made me doubt this was the implementation of storable vectors:

http://hackage.haskell.org/packages/archive/vector/0.7.1/doc/html/src/Data-V...

...

Note that a storable vector stores both a foreign pointer and a pointer (presumably so that you don't need to add an offset to the pointer, inside the foreign pointer, each time you use it):

data Vector a = Vector !(Ptr a) !Int !(ForeignPtr a)

Now, if we follow the above semantics we don't need to call withForeignPtr when we need to read the memory because the foreign pointer is referenced by the vector. However the vector library still calls withForeignPtr. For example:

basicUnsafeIndexM (Vector p _ fp) i = return . unsafeInlineIO $ withForeignPtr fp $ \_ -> peekElemOff p i

So is the withForeignPtr redundant so that this function can be rewritten to just:

basicUnsafeIndexM (Vector p _ _) i = return . unsafeInlineIO peekElemOff p i

I'd be afraid of optimizations getting ride of the constructor, and since I'm not using all of the fields I would no longer have a reference to the foreign ptr.

Since withForeignPtr touches the foreign pointer the optimizations won't make it go away no matter how it transfoms the function.

Antoine

...

Regards,

Bas

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe