[erlang-questions] enif_send from a thread after NIF returns

[Sverker Eriksson]

Joel Reymont wrote:
> On Oct 26, 2010, at 2:09 PM, Rapsey wrote:
>
>   
>> Where in the documentation does it say that? I launch my socket accept thread in load.
>>     
>
> man erl_driver
>
> /erl_drv_thread_create
>
> ---
>        The driver creating the thread has the  respon-
>        sibility  of joining the thread, via erl_drv_thread_join() , before the
>        driver is unloaded. It is not possible to  create  "detached"  threads,
>        i.e., threads that don't need to be joined.
>
>    Warning:
>        All  created  threads  need  to  be  joined  by the driver before it is
>        unloaded. If the driver fails to join all threads created before it  is
>        unloaded,  the  runtime  system will most likely crash when the code of
>        the driver is unloaded.
> ---
>
> In the context of a NIF, "driver unloaded" seems to be "NIF exits". The VM consistently crashes when I skip the join after creating threads. 
>   
You do not have to join a created thread before the nif returns. If the 
VM is crashing when a thread-creating nif returns then you are probably 
doing something wrong.

"driver unloaded" correspond to "NIF library unloaded". That is quite 
natural. Bad things will happen if a dynamic library is unloaded (driver 
or nif) while existing threads execute code in that library. A NIF 
library is only unloaded as the result of a module upgrade where  the 
old module gets purged OR if you replace a NIF library by making 
repeated calls to erlang:load_nif from the same module.

A safe way to make sure that your thread is joined before the library is 
unloaded is to create a resource object that acts as a handle to your 
thread. The destructor of the resource can then do join.
Resource objects has a protection mechanism that postpone the unloading 
of a nif library until the last resource object with a destructor in 
that library is garbage collected. Maybe nif-created threads should have 
a similar protection mechanism. Have to think about that...

/Sverker, Erlang/OTP