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

[Sverker Eriksson]

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