Age | Commit message (Collapse) | Author |
|
If we don't use per thread the value becomes completely
nonsensical on systems with more than one scheduler.
We keep the old solaris behaviour in order to support the
option, but it only really works when using a single
scheduler.
|
|
* lukas/erts/otp-21-misc:
erts: Fix unused variable warning in unix prim file
erts: Fix erts_os_times warning
kernel: Fix comment in kernel_config
kernel: Refactor erl_signal_handler startup
kernel: Remove doc for unused browser_cmd variable
|
|
|
|
|
|
Fix typos in erl_driver.xml
|
|
|
|
|
|
Introduce is_map_key/2 guard BIF
OTP-15037
|
|
* john/erts/fix-windows-symlinks/OTP-15062/ERL-615:
Stop assuming that all NTFS reparse points are links
|
|
This fixes a crash that would occur when using file:read_file_info/1
on a file with a non-link reparse point, which are commonly seen in
RSS and OneDrive folders.
|
|
* maint:
Updated OTP version
Update release notes
Update version numbers
ssl: Prepare for release
ssl: Proper handling of clients that choose to send an empty answer to a certificate request
heart: Use ntohs instead of manual conversion
|
|
|
|
|
|
into maint-20
* john/erts/fix-heart-command-overflow/OTP-15034/ERIERL-166:
heart: Use ntohs instead of manual conversion
# Conflicts:
# lib/kernel/test/heart_SUITE.erl
|
|
This reverts commit 202bb737e3deabfebee683266f4b7c42781eb521.
|
|
This reverts commit 345f7f527a4c26ef49cef0d81e2c8b71bf01ebc3.
|
|
|
|
|
|
This complements the `map_get/2` guard BIF introduced in #1784.
Rationale.
`map_get/2` allows accessing map fields in guards, but it might be
problematic in more complex guard expressions, for example:
foo(X) when map_get(a, X) =:= 1 or is_list(X) -> ...
The `is_list/1` part of the guard could never succeed since the
`map_get/2` guard would fail the whole guard expression. In this
situation, this could be solved by using `;` instead of `or` to separate
the guards, but it is not possible in every case.
To solve this situation, this PR proposes a `is_map_key/2` guard that
allows to check if a map has key inside a guard before trying to access
that key. When combined with `is_map/1` this allows to construct a
purely boolean guard expression testing a value of a key in a map.
Implementation.
Given the use case motivating the introduction of this function, the PR
contains compiler optimisations that produce optimial code for the
following guard expression:
foo(X) when is_map(X) and is_map_key(a, X) and map_get(a, X) =:= 1 -> ok;
foo(_) -> error.
Given all three tests share the failure label, the `is_map_key/2` and
`is_map/2` tests are optimised away.
As with `map_get/2` the `is_map_key/2` BIF is allowed in match specs.
|
|
* sverker/lc-thread-exit-free-fix:
erts: Fix memory leak in lock checker at thread exit
|
|
* rickard/process_info/OTP-14966:
Fix scheduled process_info() 'status' request
Fix handling of process-info requests in receive
|
|
|
|
All corba applications are moved to a separate repository.
E.g. orber, ic, cosEvent, cosEventDomain, cosNotifications
cosTime, cosTransactions, cosProperty and cosFileTransfer.
|
|
* siri/kernel/logger/OTP-13295:
Add documentation of the built-in logger handlers
Catch badarg in logger:get_format_depth/0
Add chars_limit option to logger_formatter
Don't kill logger process until all other processes are dead
Set call timeout for logger_server to infinity
Update primary bootstrap
Test cuddle for logger
Update cth_log_redirect to a logger handler
Start using logger internally in kernel and stdlib
Remove error_logger process and add logger process
Add logger
|
|
If no message/signal is sent (to same destination)
then monitor signal is flushed when process is scheduled out.
|
|
|
|
|
|
* rickard/dirty-schedulers-test-fix/OTP-15046:
Do not run tests that conflicts with dirty schedulers test
|
|
* siri/upgrade_SUITE/stop-inets-before-start-ftp:
Add correction of relup when upgrading from 20-21 with inets and ftp/tftp
|
|
Leak introduced in 865ac3b740d9efa1a0583349929591c757300412.
|
|
|
|
|
|
|
|
* rickard/process_info/OTP-14966:
Restore merge of signal queues in queue_messages() if main lock is held
Fix message tracing
|
|
Remove config test of MAP_NORESERVE for hipe on x86_64
|
|
|
|
|
|
* hasse/stdlib/map_guards_shell/OTP-15035/ERL-613:
erts: Correct abstract format doc regarding map creation
stdlib: Correct the linter's check of map guard expressions
|
|
|
|
* 'map-get-bif' of git://github.com/michalmuskala/otp:
Introduce map_get guard-safe function
OTP-15037
|
|
* lukas/erts/poll-thread/OTP-14346:
erts: nif resource stop from poll-thread is a indirect call
|
|
* lukas/erts/dump_SUITE_fix:
erts: Increase file read timeout for signal_abort test
|
|
* john/erts/fix-lcnt-toggle-test:
Disregard locks that can't be toggled in lcnt_SUITE
|
|
Improve memory instrumentation
OTP-15024
OTP-14961
|
|
|
|
Multiplying a signed char by 256 is undefined behavior and caused
problems on some platforms when the length was long enough. We
could cast it to an unsigned int to make it work, but it's best not
to reinvent the wheel.
Fixes OTP-15034
|
|
Rationale
Today all compound data types except for maps can be deconstructed in guards.
For tuples we have `element/2` and for lists `hd/1` and `tl/1`. Maps are
completely opaque to guards. This means matching on maps can't be
abstracted into macros, which is often done with repetitive guards. It
also means that maps have to be always selected whole from ETS tables,
even when only one field would be enough, which creates a potential
efficiency issue.
This PR introduces an `erlang:map_get/2` guard-safe function that allows
extracting a map field in guard. An alternative to this function would be
to introduce the syntax for extracting a value from a map that was planned
in the original EEP: `Map#{Key}`.
Even outside of guards, since this function is a guard-BIF it is more
efficient than using `maps:get/2` (since it does not need to set up the
stack), and more convenient from pattern matching on the map (compare:
`#{key := Value} = Map, Value` to `map_get(key, Map)`).
Performance considerations
A common concern against adding this function is the notion that "guards
have to be fast" and ideally execute in constant time. While there are
some counterexamples (`length/1`), what is more important is the fact
that adding those functions does not change in any way the time
complexity of pattern matching - it's already possible to match on map
fields today directly in patterns - adding this ability to guards will
niether slow down or speed up the execution, it will only make certain
programs more convenient to write.
This first version is very naive and does not perform any optimizations.
|
|
fix integer truncation bugs in error logger path
|
|
|
|
* sverker/valgrind-uninit-run_queue-ptr:
erts: Fix run queue pointer in proxy process
|