| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Do not release GVL around get{pwuid,pwnam,grgid,grnam} calls,
as doing so is not thread-safe. Another C extension could have
a concurrent call, and derefencing the returned pointer from
these calls could result in a segfault.
Have rb_home_dir_of call rb_getpwdirnam_for_login if available,
so it can use getpwnam_r and release GVL in a thread-safe manner.
This is related to GVL releasing work in [Bug #20587].
Notes:
Merged: https://github.com/ruby/ruby/pull/11202
|
|
[Feature #20590]
For better of for worse, fork(2) remain the primary provider of
parallelism in Ruby programs. Even though it's frowned uppon in
many circles, and a lot of literature will simply state that only
async-signal safe APIs are safe to use after `fork()`, in practice
most APIs work well as long as you are careful about not forking
while another thread is holding a pthread mutex.
One of the APIs that is known cause fork safety issues is `getaddrinfo`.
If you fork while another thread is inside `getaddrinfo`, a mutex
may be left locked in the child, with no way to unlock it.
I think we could reduce the impact of these problem by preventing
in for the most notorious and common cases, by locking around
`fork(2)` and known unsafe APIs with a read-write lock.
Notes:
Merged: https://github.com/ruby/ruby/pull/10864
|
|
- Extract functions to check not-found conditions
- Set the length to the result of `rb_getlogin`
- Reentrant versions return an error numeber but not `errno`
- Check maybe-undefined macros with `defined`
Notes:
Merged: https://github.com/ruby/ruby/pull/11551
|
|
|
|
It seems like no one has tried to compile on a platform without
`setsid` for almost a quarter of a century.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Exchanged with `Kernel.spawn`, like as `Kernel.exec` and
`Kernel.system`. This description should be common for these methods.
|
|
|
|
|
|
The macro SafeStringValue() became just StringValue() in c5c05460ac2,
and it is deprecated nowadays.
This patch replaces remaining macro usage. Some occurrences are left in
ext/stringio and ext/win32ole, they should be fixed upstream.
The macro itself is not deleted, because it may be used in extensions.
|
|
|
|
Revert "Remove deprecated code to fix RUBY_DEBUG build failures"
This reverts commit 9614bea2cd59902a051a7387e354e23a52fe5396.
And changed 3.4 to 3.5. To be fixed properly later.
|
|
|
|
* Allows macOS users to use M:N threads (and technically FreeBSD, though it has not been verified on FreeBSD)
* Include sys/event.h header check for macros, and include sys/event.h when present
* Rename epoll_fd to more generic kq_fd (Kernel event Queue) for use by both epoll and kqueue
* MAP_STACK is not available on macOS so conditionall apply it to mmap flags
* Set fd to close on exec
* Log debug messages specific to kqueue and epoll on creation
* close_invalidate raises an error for the kqueue fd on child process fork. It's unclear rn if that's a bug, or if it's kqueue specific behavior
Use kq with rb_thread_wait_for_single_fd
* Only platforms with `USE_POLL` (linux) had changes applied to take advantage of kernel event queues. It needed to be applied to the `select` so that kqueue could be properly applied
* Clean up kqueue specific code and make sure only flags that were actually set are removed (or an error is raised)
* Also handle kevent specific errnos, since most don't apply from epoll to kqueue
* Use the more platform standard close-on-exec approach of `fcntl` and `FD_CLOEXEC`. The io-event gem uses `ioctl`, but fcntl seems to be the recommended choice. It is also what Go, Bun, and Libuv use
* We're making changes in this file anyways - may as well fix a couple spelling mistakes while here
Make sure FD_CLOEXEC carries over in dup
* Otherwise the kqueue descriptor should have FD_CLOEXEC, but doesn't and fails in assert_close_on_exec
|
|
* Reword Range#overlap? docs last paragraph.
* Docs: add explanation about Queue#freeze
* Docs: Add :rescue event docs for TracePoint
* Docs: Enhance Module#set_temporary_name documentation
* Docs: Slightly expand Process::Status deprecations
* Fix MatchData#named_captures rendering glitch
* Improve Dir.fchdir examples
* Adjust Refinement#target docs
|
|
They are very ephemeral, so avoiding the malloc churn
is desirable.
|
|
These are not very common, but they're very easy to convert.
|
|
|
|
|
|
This patch introduce M:N thread scheduler for Ractor system.
In general, M:N thread scheduler employs N native threads (OS threads)
to manage M user-level threads (Ruby threads in this case).
On the Ruby interpreter, 1 native thread is provided for 1 Ractor
and all Ruby threads are managed by the native thread.
From Ruby 1.9, the interpreter uses 1:1 thread scheduler which means
1 Ruby thread has 1 native thread. M:N scheduler change this strategy.
Because of compatibility issue (and stableness issue of the implementation)
main Ractor doesn't use M:N scheduler on default. On the other words,
threads on the main Ractor will be managed with 1:1 thread scheduler.
There are additional settings by environment variables:
`RUBY_MN_THREADS=1` enables M:N thread scheduler on the main ractor.
Note that non-main ractors use the M:N scheduler without this
configuration. With this configuration, single ractor applications
run threads on M:1 thread scheduler (green threads, user-level threads).
`RUBY_MAX_CPU=n` specifies maximum number of native threads for
M:N scheduler (default: 8).
This patch will be reverted soon if non-easy issues are found.
[Bug #19842]
|
|
Remove the bad example that can lead to misunderstanding as if this
precision is defined in Ruby.
|
|
|
|
|
|
|
|
|
|
Similar to releasing free GC pages, releasing free malloc pages
reduce the amount of page faults post fork.
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/8392
|
|
`Process::Status#&` and `Process::Status#>>` are provided only for
the backward compatibility with older Ruby than 1.8 where `$?` was
a `Fixnum`, and the knowledge about internals of system dependent
macros is necessary to use them. Modern programs and libraries
should not need these methods.
Notes:
Merged: https://github.com/ruby/ruby/pull/8392
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/8392
|
|
Notes:
Merged-By: peterzhu2118 <[email protected]>
|
|
|
|
Notes:
Merged-By: peterzhu2118 <[email protected]>
|
|
Notes:
Merged-By: peterzhu2118 <[email protected]>
|
|
|
|
- Signal names can be symbols, as stated above.
- Supported signals and those values are platform dependent.
- Key sequences to send signal are configurable.
- Fix description of signal 0.
Co-authored-by: Peter Zhu <[email protected]>
Notes:
Merged: https://github.com/ruby/ruby/pull/8367
Merged-By: nobu <[email protected]>
|
|
Notes:
Merged-By: peterzhu2118 <[email protected]>
|
|
Notes:
Merged-By: peterzhu2118 <[email protected]>
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/8361
|
|
Notes:
Merged-By: peterzhu2118 <[email protected]>
|
|
Notes:
Merged-By: peterzhu2118 <[email protected]>
|
|
Notes:
Merged-By: peterzhu2118 <[email protected]>
|
