From 730b5c14a33800bb5b0c19e8e48b213e07402179 Mon Sep 17 00:00:00 2001
From: Rickard Green The
If the NIF call is too lenghty one needs to handle this in one of the
+ If the NIF call is too lengthy one needs to handle this in one of the
following ways in order to avoid degraded responsiveness, scheduler load
- balancing problems, and other strange behaviours:
A lot of operations communicating with a process executing a
dirty NIF can, however, complete while it is executing the
- dirty NIF. For example, retreiving information about it via
+ dirty NIF. For example, retrieving information about it via
Termination of a process executing a dirty NIF can only be completed up to a certain point while it is executing the - dirty NIF. All Erlang resources such as registered names, - ETS tables, etc will be released. All links and monitors + dirty NIF. All Erlang resources such as its registered name, + its ETS tables, etc will be released. All links and monitors will be triggered. The actual execution of the NIF will - however not be stopped. The NIF can safely contiue + however not be stopped. The NIF can safely continue execution, allocate heap memory, etc, but it is of course better to stop executing as soon as possible. The NIF can check whether current process is alive or not using @@ -450,8 +450,8 @@ ok collect a process in order to determine if it has references to the module, a process executing a dirty NIF might delay purging for a very long time. Delaying - a purge operatin implies delaying all code - loding operations which might cause severe problems for + a purge operation implies delaying all code + loading operations which might cause severe problems for the system as a whole.
-- cgit v1.2.3