| Age | Commit message (Collapse) | Author |
|---|
|
where string:trim does not exist.
|
|
git cherry-pick 75b0f73f72e1783d4ace976cdd2b5f23bdc3ebae
|
|
git cherry-pick 55e929c4ed5cd854038c18697123ea94948ebf35
|
|
|
|
When a generator in a list comprehension was given some
other term than a list, the wrong line could be pointed
out in the exception. Here is an example:
bad_generator() ->
[I || %%This line would be pointed out.
I <- not_a_list].
https://bugs.erlang.org/browse/ERL-572
|
|
statistics(runtime) does not seem to work on some virtual machines.
|
|
|
|
Implementation of true asynchronous signaling between processes
|
|
All uses of async threads in the built-in drivers have been
replaced with dirty IO, so it no longer makes sense to leave the
default at 10.
|
|
Communication between Erlang processes has conceptually always been
performed through asynchronous signaling. The runtime system
implementation has however previously preformed most operation
synchronously. In a system with only one true thread of execution, this
is not problematic (often the opposite). In a system with multiple threads
of execution (as current runtime system implementation with SMP support)
it becomes problematic. This since it often involves locking of structures
when updating them which in turn cause resource contention. Utilizing
true asynchronous communication often avoids these resource contention
issues.
The case that triggered this change was contention on the link lock due
to frequent updates of the monitor trees during communication with a
frequently used server. The signal order delivery guarantees of the
language makes it hard to change the implementation of only some signals
to use true asynchronous signaling. Therefore the implementations
of (almost) all signals have been changed.
Currently the following signals have been implemented as true
asynchronous signals:
- Message signals
- Exit signals
- Monitor signals
- Demonitor signals
- Monitor triggered signals (DOWN, CHANGE, etc)
- Link signals
- Unlink signals
- Group leader signals
All of the above already defined as asynchronous signals in the
language. The implementation of messages signals was quite
asynchronous to begin with, but had quite strict delivery constraints
due to the ordering guarantees of signals between a pair of processes.
The previously used message queue partitioned into two halves has been
replaced by a more general signal queue partitioned into three parts
that service all kinds of signals. More details regarding the signal
queue can be found in comments in the erl_proc_sig_queue.h file.
The monitor and link implementations have also been completely replaced
in order to fit the new asynchronous signaling implementation as good
as possible. More details regarding the new monitor and link
implementations can be found in the erl_monitor_link.h file.
|
|
|
|
|
|
* bjorn/misc-beam-fixes:
Correctly handle get_map_elements with a literal map
core_parse: Fix handling of negative sizes in binaries
|
|
Remove unused cerl_messagean module
|
|
|
|
* sverker/inline-sys_memcpy:
erts: Optimize macro DMC_PUSH
erts: Make sys_memcpy and friends inline functions
|
|
to call a common static function dmc_stack_grow()
and reduce the code bloat.
and did a combined DMC_PUSH2
|
|
to avoid argument-evaluated-twice bugs
like in macro DMC_PUSH.
Had to shuffle around some #include and #define
to make erl_child_setup build debug target.
|
|
|
|
kernel: in the group added processing of 'EXIT' signal from shell
OTP-14991
|
|
stdlib: Add function lists:search/2
|
|
Short-circuit code:ensure_loaded for already-loaded modules
|
|
More typos
|
|
* john/erts/fix-set-owner-group/ERL-589:
Fix file:change_group/change_owner
|
|
|
|
|
|
|
|
A get_map_elements instruction that has a literal map operand
would never be translated to a i_get_map_element instruction.
That would be a problem for the following instruction:
get_map_elements Fail #{} {x,0}, {x,1}
Since the key is not a literal, get_map_element must be used,
since get_map_elements requires that a hash value can be
calculated for each element.
When the instruction is translated to i_get_map_element, the
hash value will be set to 0 and an assertion will trigger in
the debug build.
|
|
A literal negative size in binary construction would cause a crash.
|
|
* bjorn/compiler/misc-fixes:
Teach beam_utils:replace_labels/4 to handle recv_{mark,set}
v3_kernel: Stop ensuring one return value in #k_try{}
v3_kernel_pp: Print return variables for #k_try{}
|
|
It wasn't possible to change group/owner separately, and our test
suite lacked coverage for that.
ERL-589
|
|
* hans/ssh/faster_app_stop/OTP-14988:
ssh: Remove deadlock in supervisor tree
ssh: Remove spawn in ssh_system_sup:stop_system/1
ssh: Removed unused sshc_sup:stop_child/1
|
|
* hans/ssh/cuddle_tests_master:
ssh: Join basic and renegotiation suites and parallelize
ssh: Parallelize ssh_basic_SUITE
ssh: Parallelize ssh_renegotiate_SUITE
ssh: Fix non-working test + add log in test suite
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* maint:
Updated OTP version
Update release notes
ssl: Prepare for release
ssl: Remove duplicate release note
ssl: Fix filter function to not discard AEAD cipher suites
Conflicts:
OTP_VERSION
|
|
|
|
|
|
make erlang:process_info/1 not retrieve messages
|
|
Fix typos in erl_nif.xml
|
|
Tracing MatchSpec docs update
|
|
I was running this code in shell and expected it to take default `self()` meta tracer,
and start tracing `erlang:put/2`.
```
F = fun F() -> timer:sleep(5000), erlang:get(unique_field), erlang:put(unique_field, 123), F() end.
erlang:trace_pattern({erlang, put, 2}, [{['$1', '_'], [{'==', '$1', unique_field}], []}], [global]).
erlang:trace_pattern({erlang, get, 1}, [{['_'], [], [{trace, [], [call, timestamp]}]}], [meta]).
Pid = spawn(F).
```
But tracing didn't start:
```
6> flush().
Shell got {trace_ts,<0.70.0>,call,
{erlang,get,[unique_field]},
{1521,118606,753838}}
Shell got {trace_ts,<0.70.0>,call,
{erlang,get,[unique_field]},
{1521,118611,754798}}
Shell got {trace_ts,<0.70.0>,call,
{erlang,get,[unique_field]},
{1521,118616,755705}}
ok
7> erlang:trace_info(Pid, flags).
{flags,[]}
```
Turns out that I had false expectations, that `{trace, _, _}` would enable tracing on that process, inheriting meta tracer process as consumer of trace messages.
Instead it tried to take tracer from executing process (which is pointed out in docs). But there was none, so no tracing was started and flags were simply ignored (which is not that obvious from docs).
Updated docs to point out that there are cases when flags would be simply ignored, and no tracing would start.
|
|
|
|
|
|
|
