| Age | Commit message (Collapse) | Author |
|---|
|
putenv(3) and friends aren't thread-safe regardless of how you slice
it; a global lock around all environment operations (like before)
keeps things safe as far as our own operations go, but we have
absolutely no control over what libc or a library dragged in by a
driver/NIF does -- they're free to call getenv(3) or putenv(3)
without honoring our lock.
This commit solves this by setting up an "emulated" environment which
can't be touched without going through our interfaces. Third-party
libraries can still shoot themselves in the foot but benign uses of
os:putenv/2 will no longer risk crashing the emulator.
|
|
|
|
The implementation is still hidden behind ERTS_ENABLE_LOCK_COUNT, and
all categories are still enabled by default, but the actual counting can be
toggled at will.
OTP-13170
|
|
|
|
|
|
New BIF os:unsetenv/1 which deletes an environment variable and
returns 'true'.
Does not change any old functionality.
Calls the libc function unsetenv(3) on UNIX and
SetEnvironmentVariableW(key, NULL) on Windows. The unicode support
is the same as for os:getenv and os:putenv.
|
|
|
|
Putenv and getenv needs to convert to the proper environment
strings in Unicode depending on platform and user settings for filename
encoding. Also erlexec needs to pass environment strings in an appropriate
way for kernel to pick up. All environment strings on the command
line, as well as home directory, is now passed in UTF8 on windows
and in whatever encoding you have on Unix, kernel tries to convert all
parameters and environments from UTF8 before making strings.
|
|
|
|
Queues used for communication between async threads and scheduler threads
have been replaced with lock-free queues.
Drivers using the driver_async functionality are not automatically locked
to the system anymore, and can be unloaded as any dynamically linked in
driver.
Scheduling of ready async jobs is now also interleaved in between other
jobs. Previously all ready async jobs was performed at once.
|
|
* se/port_SUITE_env:
fix open_port with many unset env vars
allow open_port with env vars with trailing '=' on Windows
OTP-8701 se/port_SUITE_env
open_port/2 with the spawn and spawn_executable options can include an
{env,Env} option. In some cases unsetting variables would not work on Unix
(typically if more variables were unset than were actually present in the
environment).
|
|
Same problem that Steve Vinoski fixed for Unix. Similar fix done in
erts/emulator/sys/win32/sys_env.c for Windows.
Copy-paste from his commit-message:
The erlang:open_port spawn and spawn_executable directives can include
an {env, Env} directive to set up environment variables for the
spawned process. A bug in ert/emulator/sys/unix/sys.c prevented
applications from using {env, Env} to set an environment variable
whose value ended with a '=' (equal sign) character; the code mistook
the trailing equal sign as an indication that an environment variable
was to be cleared from the environment of the spawned process.
For example, passing an {env, Env} of
{env, [{"foo", "bar="}]}
would result in the code in sys.c seeing a string of the form
"foo=bar="
The code would see the final '=' character and assume the directive
wanted to clear a variable named "foo=bar" from the environment of the
spawned process, rather than seeing it as a directive to set the
environment variable "foo" to the value "bar=".
|
|
|
