[erlang-questions] Do you wanna play with enif_select?

Daniel Goertzen daniel.goertzen@REDACTED
Fri Dec 9 00:06:09 CET 2016


Thank you for answering my questions.  I understand this API much better
now and look forward to its release.

On Thu, Dec 8, 2016 at 9:17 AM Sverker Eriksson <
sverker.eriksson@REDACTED> wrote:

> On 12/07/2016 09:41 PM, Daniel Goertzen wrote:
> > The presence of the resource makes sense.  But why the special close/stop
> > methods?  Is the existing destructor insufficient in some way?
> >
>
> The resource destructor will not be called until all references
> to the resource is gone (by term GC and/or enif_release_resource
> calls from NIF code).
>
> It must be possible to close a file descriptor (think TCP connection)
> associated with a resource without having to wait for the GC. If the
> resource have been shared among a number of processes it might
> take a while until all references are purged on all heaps and the
> destructor is finally called.
>
> Also, it is undefined behaviour (according to POSIX) to close a file
> descriptor
> that another thread is doing select/poll on. So, to safely call close on
> a file
> descriptor we first may have to wait for a polling thread to wake up. We
> don't want blocking waits between scheduler threads, so we need a
> scheduled callback when the fd is safe to close.
>
>
> Summary:
> We don't want to wait for the GC but we may need to wait for polling
> thread, hence the stop/close callback (or whatever it should be called).
>
> /Sverker
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20161208/df01ca7b/attachment.htm>


More information about the erlang-questions mailing list