ruby.git/debug.c, branch v3_3_11

M:N thread scheduler for Ractors

2023-10-12T05:47:01+00:00

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]

`RUBY_DEBUG_LOG` supports `%p` for pid

2023-10-11T18:14:39+00:00

Hide the usage of `rb_io_t` where possible. (#7880)

2023-06-01T05:23:30+00:00

This retries the compatible parts of the previously reverted PR so we can continue to update related code without breaking backwards compatibility.

Revert "Hide most of the implementation of `struct rb_io`. (#6511)"

2023-05-31T23:43:22+00:00

This reverts commit 18e55fc1e1ec20e8f3166e3059e76c885fc9f8f2.

fix [Bug #19704]
https://bugs.ruby-lang.org/issues/19704
This breaks compatibility for extension libraries. Such changes
need a discussion.

Hide most of the implementation of `struct rb_io`. (#6511)

2023-05-30T01:02:40+00:00

* Add rb_io_path and rb_io_open_descriptor.

* Use rb_io_open_descriptor to create PTY objects

* Rename FMODE_PREP -> FMODE_EXTERNAL and expose it

FMODE_PREP I believe refers to the concept of a "pre-prepared" file, but
FMODE_EXTERNAL is clearer about what the file descriptor represents and
aligns with language in the IO::Buffer module.

* Ensure that rb_io_open_descriptor closes the FD if it fails

If FMODE_EXTERNAL is not set, then it's guaranteed that Ruby will be
responsible for closing your file, eventually, if you pass it to
rb_io_open_descriptor, even if it raises an exception.

* Rename IS_EXTERNAL_FD -> RUBY_IO_EXTERNAL_P

* Expose `rb_io_closed_p`.

* Add `rb_io_mode` to get IO mode.

---------

Co-authored-by: KJ Tsanaktsidis

Rename `rb_node_name` to the original name

2023-05-24T11:54:48+00:00

98637d421dbe8bcf86cc2effae5e26bb96a6a4da changes the name of
the function. However this function is exported as global,
then change the name to origin one for keeping compatibility.

Move `ruby_node_name` to node.c and rename prefix of the function

2023-05-23T09:05:35+00:00

`rb_bug` prints a newline after the message

2023-05-20T12:43:30+00:00

show a separator even if `ec` is NULL.

2023-04-26T08:57:32+00:00

`RUBY_DEBUG_LOG()` doesn't show anything if `GET_EC()` returns NULL,
but print a separator "\t" to make consistent TSV.

`RUBY_DEBUG_LOG_PID` for `RUBY_DEBUG_LOG()`

2023-04-26T08:57:32+00:00

`RUBY_DEBUG_LOG=stderr RUBY_DEBUG_LOG_PID=1 ruby ...` will prints
debug logs with PID.