<p>Sending to the list as well.</p>
<div class="gmail_quote">On Jun 19, 2011 9:58 AM, "Antoine Latter" <<a href="mailto:aslatter@gmail.com">aslatter@gmail.com</a>> wrote:<br type="attribution">> On Jun 19, 2011 7:49 AM, "Bas van Dijk" <<a href="mailto:v.dijk.bas@gmail.com">v.dijk.bas@gmail.com</a>> wrote:<br>
>><br>>> On 19 June 2011 14:13, wren ng thornton <<a href="mailto:wren@freegeek.org">wren@freegeek.org</a>> wrote:<br>>> > The documentation claims that<br>>> > the finalizers are run only once the ForeignPtr becomes unreachable,<br>
> which<br>>> > implies that keeping the ForeignPtr is sufficient to keep the foreign<br>>> > object alive.<br>>><br>>> Right, that was also my thinking when designing the usb library. What<br>
>> made me doubt this was the implementation of storable vectors:<br>>><br>>><br>> <a href="http://hackage.haskell.org/packages/archive/vector/0.7.1/doc/html/src/Data-Vector-Storable.html">http://hackage.haskell.org/packages/archive/vector/0.7.1/doc/html/src/Data-Vector-Storable.html</a><br>
>><br>>> Note that a storable vector stores both a foreign pointer and a<br>>> pointer (presumably so that you don't need to add an offset to the<br>>> pointer, inside the foreign pointer, each time you use it):<br>
>><br>>> data Vector a = Vector !(Ptr a) !Int !(ForeignPtr a)<br>>><br>>> Now, if we follow the above semantics we don't need to call<br>>> withForeignPtr when we need to read the memory because the foreign<br>
>> pointer is referenced by the vector.<br>>> However the vector library still calls withForeignPtr. For example:<br>>><br>>> basicUnsafeIndexM (Vector p _ fp) i = return<br>>> . unsafeInlineIO<br>
>> $ withForeignPtr fp $ \_ -><br>>> peekElemOff p i<br>>><br>>> So is the withForeignPtr redundant so that this function can be<br>
>> rewritten to just:<br>>><br>>> basicUnsafeIndexM (Vector p _ _) i = return<br>>> . unsafeInlineIO<br>>> peekElemOff p i<br>
>><br>> <br>> I'd be afraid of optimizations getting ride of the constructor, and since<br>> I'm not using all of the fields I would no longer have a reference to the<br>> foreign ptr.<br>> <br>
> Since withForeignPtr touches the foreign pointer the optimizations won't<br>> make it go away no matter how it transfoms the function.<br>> <br>> Antoine<br>> <br>>> Regards,<br>>><br>>> Bas<br>
>><br>>> _______________________________________________<br>>> Haskell-Cafe mailing list<br>>> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>>> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div>