[erlang-questions] How to properly stop complicated async NIF resource.
Mikael Karlsson
karlsson.rm@REDACTED
Thu Jul 18 03:19:52 CEST 2019
Wed 17 July 2019 21:45 Max Lapshin <max.lapshin@REDACTED> wrote:
> I'm afraid of the situation when the only resource owner is killed and
> resource must be destroyed by calling destructor.
>
> It is too late to call to erlang at this time =(
>
> However, your idea is interesting. I can register some destruction
> manager just like a "hier" in ets and when resource is going to be killed,
> or its owner is going to be killed, we send a message to the "destruction
> manager" and it will clean without these messy cond_wait_timeout calls.
>
I think I understand....
In my case I do not even register a destructor callback since I do not need
to.
Just some other ideas, maybe it is possible to use the
enif_open_resource_type_x function to register a "down" function and then
monitor your resource owner process from the thread with
enif_monitor_process. I guess that the down callback would be called from
within your thread and then you could cleanup in that without the need of
mutexes and cond_wait_timout calls.
Or if enif_send is called often you could check if it returns false, which
means that to_pid or sender is not alive, and then perform cleanup in that
case.
<http://erlang.org/doc/man/erl_nif.html#enif_open_resource_type_x>
Also just to be clear, even if you start a thread from an API it will run
within the erlang VM if you can call enif_send:
http://erlang.org/pipermail/erlang-questions/2019-May/097983.html
It took me some time (and help from OTP developer) to understand this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20190718/e4a276a3/attachment.htm>
More information about the erlang-questions
mailing list