| Age | Commit message (Collapse) | Author |
|---|
|
Add syntax in try/catch to retrieve the stacktrace directly
|
|
There doesn't seem to be any science behind the long delays, and
the (newly introduced) dry run forces us to eat them twice, so
they've been shortened to more reasonable values.
|
|
Code loading is done through dirty IO now, causing the
dirty_scheduler_exit tests to fail as they block their own progress
by invoking erts_debug:dirty_io(wait, _); the spawned processes
will exit normally before we have a chance to kill them.
To get around this, we perform a dry run to ensure that all required
code is loaded. It isn't particularly pretty (or fast) but it saves
us the hassle of maintaining a module list (cf. embedded mode).
|
|
|
|
#### 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.
|
|
|
|
|
|
|
|
|
|
* rickard/time-unit/OTP-13735:
Update test-cases to use new symbolic time units
Replace misspelled symbolic time units
Conflicts:
erts/doc/src/erlang.xml
erts/emulator/test/long_timers_test.erl
|
|
* rickard/test-cuddle:
Fix dirty_nif_SUITE:dirty_call_while_terminated test case
Adjust process_SUITE:no_priority_inversion2
Allow larger timeout delay in driver_SUITE
Ignore long time failures during high CPU utilization
Cleanup in statistics_SUITE:runtime_update test
Improve timer tests in driver_SUITE
Fix statistics_SUITE:scheduler_wall_time test
Fix scheduler_SUITE:scheduler_suspend test
Fix scheduler_SUITE:scheduler_threads test
Fix scheduler_SUITE:update_cpu_info test
Skip nif_SUITE:consume_timeslice test when debug compiled
Increase time margin in timer_bif_SUITE:start_timer_1 test
|
|
Prevent binary from being prematurely GCed
|
|
|
|
|
|
|
|
Dirty schedulers only execute NIFs, so having them execute the full
process_main function isn't necessary. Add dirty_process_main for
dirty schedulers to execute instead.
Add erts_pre_dirty_nif(), called when preparing to execute a dirty
nif.
Add more dirty NIF tests to verify that activities requiring the
process main lock can succeed when the process is executing a dirty
NIF.
|
|
|
|
|
|
|
