| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
This reverts commit 425889ba69b69a9b6fb14bfbef121d51b78e853a.
|
|
|
|
A multitude of broken links were found when a bug was fixed
in the link checker.
|
|
This reverts commit 0118046f9bda8dcf3594184fa439b79267db8017.
|
|
|
|
This helps avoid long sequences of enif_is_xxx in code that
serializes terms (such as JSON encoders) by letting the user
switch on the type.
|
|
This reverts commit df130102cdeca8d35fec95a0c926fd1cfec54eab.
|
|
|
|
fix broken html link
|
|
as a macro wrappper around enif_compare
|
|
|
|
for enif_send and enif_select_read|write.
|
|
|
|
|
|
|
|
|
|
introduced after OTP_R13B03.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
to deselect read and/or writes without stop callback.
|
|
|
|
to include ports and NIF resources.
Added new opaque type 'nif_resource'.
|
|
|
|
|
|
|
|
|
|
to conform with erl_nif.h
|
|
|
|
|
|
|
|
Fix typos in erl_nif.xml
|
|
|
|
|
|
|
|
While enif_make_binary will create heap-binaries from ErlNifBinaries
when possible now, enif_alloc_binary still allocates a Binary* off-heap
which is avoided entirely with enif_make_new_binary.
|
|
|
|
This introduces a way to retrieve erlang terms from NIF IO queues
without having to resort to copying.
OTP-14797
|
|
|
|
|
|
* sverker/nif-resource-doc:
erts: Update docs for enif_make_resource
|
|
to include new defined properties in OTP-20
regarding comparison and serialization.
|
|
|
|
#### Why do we need this new feature?
There are cases when a NIF needs to send a message, using `enif_send()`, to a long-lived process with a registered name.
A common use-case is logging, where asynchronous fire-and-forget messages are the norm.
There can also be cases where a yielding or dirty NIF or background thread may request a callback from a service with additional information it needs to complete its operation, yielding or waiting (with suitable timeouts, etc) until its state has been updated through the NIF module's API.
NIFs can only send messages to pids, and the lack of name resolution leaves a complicated dance between separate monitoring processes and the NIF as the only way to keep a NIF informed of the whereabouts of such long-lived processes.
Providing a reliable, built-in facility for NIFs to resolve process (or port) names simplifies these use cases considerably.
#### Risks or uncertain artifacts?
Testing has not exposed any significant risk.
The implementation behaves as expected on regular and dirty scheduler threads as well as non-scheduler threads.
By constraining the `enif_whereis_...()` functions to their minimal scopes and using patterns consistent with related functions, the implementation, testing, and maintenance burden is low.
The API and behavior of existing functions is unchanged.
#### How did you solve it?
While extending `enif_send()` to operate on a pid or an atom (as `erlang:send/2` does) was attractive, it would have entailed changing the type of its `to_pid` parameter and thereby breaking backward compatibility.
The same consideration applies to `enif_port_command()`.
That leaves a choice between 1, 2, or 3 new functions:
1. `enif_whereis()`
2. `enif_whereis_pid()` and `enif_whereis_port()`
3. All of the above.
While option (1), directly mimicking the behavior of `erlang:whereis/1`, is appealing, it poses potential problems if `pid()` or `port()` are subsequently implemented as non-integral types that must be bound to an owning `ErlNifEnv` instance.
Therefore, option (2) has been chosen to use `ErlNifPid`/`ErlNifPort` structures in the API to maintain proper term ownership semantics.
|
|
|
