[Haskell-cafe] Semantics of ForeignPtr Finalizers

[Antoine Latter]

Sending to the list as well.
On Jun 19, 2011 9:58 AM, "Antoine Latter" <aslatter at gmail.com> wrote:
> On Jun 19, 2011 7:49 AM, "Bas van Dijk" <v.dijk.bas at gmail.com> wrote:
>>
>> On 19 June 2011 14:13, wren ng thornton <wren at freegeek.org> 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-Vector-Storable.html
>>
>> 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20110619/b1ac3d40/attachment.htm>