Kill a NIF's process

[Sverker Eriksson]

At process termination the deallocation of the heap is delayed until a running 
dirty NIF has returned. This to make sure the dirty NIF can safely continue 
read its arguments.



The firing of links and monitors (including NIF monitor down calls), on the 
other hand, are not delayed by a running dirty NIF.



I hope that answered the question.



/Sverker, Erlang/OTP



From: erlang-questions <erlang-questions-bounces@REDACTED> On Behalf Of 
Robert Harris
Sent: den 21 april 2021 18:06
To: erlang-questions@REDACTED
Subject: Kill a NIF's process



Hello all.

Suppose there is a dirty NIF that is associated with a resource object
initialised with a down callback. Further, the NIF is passed some term
that it spends a long time examining; for the sake of argument, it
repeatedly reads the memory underlying a binary.

If the process is killed, e.g. by exit/2, is the NIF's resource object's
down callback called before the VM releases terms in the victim's
environment (e.g. the term whose memory the NIF is reading)? If so,
does releasing block on the down callback?

Regards,

Robert Harris
Confidentiality Notice | This email and any included attachments may be 
privileged, confidential and/or otherwise protected from disclosure. Access to 
this email by anyone other than the intended recipient is unauthorized. If you 
believe you have received this email in error, please contact the sender 
immediately and delete all copies. If you are not the intended recipient, you 
are notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.



Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby 
notified that any disclosure, copying, distribution or taking action in 
relation of the contents of this information is strictly prohibited and may be 
unlawful.

This email has been scanned for viruses and malware, and may have been 
automatically archived by Mimecast, a leader in email security and cyber 
resilience. Mimecast integrates email defenses with brand protection, security 
awareness training, web security, compliance and other essential capabilities. 
Mimecast helps protect large and small organizations from malicious activity, 
human error and technology failure; and to lead the movement toward building a 
more resilient world. To find out more, visit our website.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20210421/4a5cf4c4/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5509 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20210421/4a5cf4c4/attachment.bin>