<div dir="ltr"><div>Yes, this can happen even if you're opaque and don't export stuff.</div><div><br></div>You could attach the finalizer to an (unpacked) IORef that holds the Bool that says whether you've been finalized. An IORef holds onto a MutVar# under the hood, and so it also maintains the same sort of stable presence Weak# offered above. Similarly you _could_ just stuff the info in an MVar or ForeignPtr. Each of those has support for attaching a finalizer directly to the heap allocated part that lives in # and therefore isn't vulnerable to being inlined or unpacked.<div><br></div><div>There probably should be able to be similar options for attaching the finalizer to a MutableByteArray#, even if the combinators don't exist right now, etc.<div><br></div></div><div>I'd personally go with an IORef and then atomicModifyIORef during the "close" and "finalize" operations to extract and set the flag in one operation. That way there isn't any communication overhead, but IORef, ForeignPtr, MVar, etc. could all work.</div><div><br></div><div>-Edward</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 30, 2018 at 5:09 PM, Viktor Dukhovni <span dir="ltr"><<a href="mailto:ietf-dane@dukhovni.org" target="_blank">ietf-dane@dukhovni.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
> On Jan 30, 2018, at 4:50 PM, Edward Kmett <<a href="mailto:ekmett@gmail.com">ekmett@gmail.com</a>> wrote:<br>
><br>
> It would be much, much safer to attach the finalizer to something that has a "presence" all its own, like Weak# () as is done in ForeignPtr. This would result in something like:<br>
><br>
> data Socket = Socket !CInt (Weak# ())<br>
><br>
> Then when it gets unpacked into another data constructor, then the Weak# () still exists. This isn't free, it comes at the cost that your sockets take a couple of words each (plus finalizer space), but the approach you are taking now isn't free either as it isn't really sound. ;)<br>
><br>
> tl;dr don't attach finalizers to regular Haskell data types if you can help it<br>
<br>
</span>THanks, good to know. I gather the unpacking can/will happen even if<br>
Socket internals are [made] opaque to other modules?<br>
<br>
And of course in this case, in addition to avoiding<br>
running the finalizer too early, it is critical that each socket be closed<br>
at most once. Therefore, to support finalization, and make the API safe<br>
for multiple close (as seems to be the case with System.IO Handle's for<br>
example) there's a need for additional mutable state in the Socket, to<br>
keep track of whether it has or has not yet been closed.<br>
<br>
I am curious as to what your suggestion would be as to how to best keep<br>
track of such state.<br>
<br>
1. Employ a separate MVar to keep track of socket state, and update<br>
it on close to ensure at most once close.<br>
<br>
2. Wrap the file descriptor in an IORef, and set it to an invalid<br>
value (-1 on Unix, INVALID_SOCKET on Windows) on close. This<br>
avoids misuse not only with close, but also with attempts at<br>
read/write/... I/O after close. However it does not avoid<br>
(far less likely I think) races to close the socket from<br>
multiple threads.<br>
<br>
3. Move the state to a wrapper structure managed in FFI code<br>
so that all socket operations are via a foreign pointer to<br>
a C-structure in which the file descriptor is invalidated on<br>
close.<br>
<br>
4. Other suggestions...<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Viktor.<br>
<br>
______________________________<wbr>_________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/haskell-<wbr>cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</div></div></blockquote></div><br></div>