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]
* `-j` option for concurrent test with threads
* `-jN` uses N threads
* `-j` uses nproc/2 threads
* Introduce `BT` struct to manage configurations
* Introduce `Assertion` to manage all assertions
* Remove all toplevel instance variables
* Show elapsed seconds at last
```
$ time make btest
...
real 0m37.319s
user 0m26.221s
sys 0m16.534s
$ time make btest TESTOPTS=-j
...
real 0m11.812s
user 0m36.667s
sys 0m21.872s
```
rb_uninterruptible() disables any interrupts using handle_interrupt
feature (This function is used by `p`).
After this function, pending interrupts should be checked correctly,
however there is no chance to setup interrupt flag of working
threads, it means that nobody checks pending interrupts.
For example, it ignores terminate signal delivered at the end
of main thread and program can't stop.
This patch set interrupt flag if there are pending interrupts.
On Deiban 9 environment, the thread tests failed and
this maximum threads information can finish up the machine
resources. To check it, I turned-off showing this information.
* bootstraptest/test_thread.rb: remove a garbage line for debug.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@46380 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* bootstraptest/test_thread.rb: String#=~ does not accept String.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@44016 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
threads.
This benchmark seems consuming long time on travis-ci
several times (and make `failure').
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@37859 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
between onceinlinecache and setinlinecache. [ruby-dev:39768]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@27515 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
at fork to get rid of deadlock. based on the patch from Hongli
Lai in [ruby-core:26783]. [ruby-core:26361]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@25842 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
object become dummy because of fork. [ruby-core:26744]
[ruby-core:26745]
* bootstraptest/test_thread.rb: add a test for above.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@25771 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
set a VM_FRAME_FLAG_PASSED flag to skip this frame when
searching ruby-level-cfp.
* eval.c, eval_intern.h, proc.c: fix to check cfp. if there is
no valid ruby-level-cfp, cause RuntimeError exception.
[ruby-dev:34128]
* vm_core.h, vm_evalbody.c, vm.c, vm_dump.c, vm_insnhelper.c,
insns.def: rename FRAME_MAGIC_* to VM_FRAME_MAGIC_*.
* KNOWNBUGS.rb, bootstraptest/test*.rb: move solved bugs.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@17084 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Koichi Sasada
Takashi Kokubun
Nobuyoshi Nakada
Samuel Williams
git
k0kubun
nobu
akr
ko1
mame
usa
matz