/spec/ruby/shared/io/

• ../
• putc.rb

	index : ruby.git	master ruby_1_3 ruby_1_4 ruby_1_6 ruby_1_8 ruby_1_8_5 ruby_1_8_6 ruby_1_8_7 ruby_1_9_1 ruby_1_9_2 ruby_1_9_3 ruby_2_0_0 ruby_2_1 ruby_2_2 ruby_2_3 ruby_2_4 ruby_2_5 ruby_2_6 ruby_2_7 ruby_3_0 ruby_3_1 ruby_3_2 ruby_3_3 ruby_3_4 ruby_4_0 v1_0r v1_1dev v1_1r
	The Ruby Programming Language

summaryrefslogtreecommitdiff

log msg author committer range

path: root/thread_win32.h

Age	Commit message (Collapse)	Author
2023-10-12	M:N thread scheduler for Ractors	Koichi Sasada
	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]
2023-05-26	Move rb_thread_cond_struct definition into thread_native.h	KJ Tsanaktsidis
	On Win32, currently, rb_nativethread_cond_t is an incomplete type because it's a typedef for `struct rb_thread_cond_struct`. That means you can't actually allocate a rb_nativethread_cond_t unless you also include THREAD_IMPL_H (since its defined in thread_win32.h) (alternatively, including vm_core.h also works). Move the definition of rb_thread_cond_struct into thread_native.h to alleviate this. Notes: Merged: https://github.com/ruby/ruby/pull/7865
2022-05-24	`native_tls_get()`' should not check results	Koichi Sasada
	caller should check the result of `native_tls_get()`. Notes: Merged: https://github.com/ruby/ruby/pull/5933
2022-04-23	introduce struct `rb_native_thread`	Koichi Sasada
	`rb_thread_t` contained `native_thread_data_t` to represent thread implementation dependent data. This patch separates them and rename it `rb_native_thread` and point it from `rb_thraed_t`. Now, 1 Ruby thread (`rb_thread_t`) has 1 native thread (`rb_native_thread`). Notes: Merged: https://github.com/ruby/ruby/pull/5836
2022-04-22	rename thread internal naming	Koichi Sasada
	Now GVL is not process *Global* so this patch try to use another words. * `rb_global_vm_lock_t` -> `struct rb_thread_sched` * `gvl->owner` -> `sched->running` * `gvl->waitq` -> `sched->readyq` * `rb_gvl_init` -> `rb_thread_sched_init` * `gvl_destroy` -> `rb_thread_sched_destroy` * `gvl_acquire` -> `thread_sched_to_running` # waiting -> ready -> running * `gvl_release` -> `thread_sched_to_waiting` # running -> waiting * `gvl_yield` -> `thread_sched_yield` * `GVL_UNLOCK_BEGIN` -> `THREAD_BLOCKING_BEGIN` * `GVL_UNLOCK_END` -> `THREAD_BLOCKING_END` * removed * `rb_ractor_gvl` * `rb_vm_gvl_destroy` (not used) There are GVL functions such as `rb_thread_call_without_gvl()` yet but I don't have good name to replace them. Maybe GVL stands for "Greate Valuable Lock" or something like that. Notes: Merged: https://github.com/ruby/ruby/pull/5814
2021-09-03	Get rid of duplicate typedef	Nobuyoshi Nakada
2020-11-18	fix public interface	Koichi Sasada
	To make some kind of Ractor related extensions, some functions should be exposed. * include/ruby/thread_native.h * rb_native_mutex_* * rb_native_cond_* * include/ruby/ractor.h * RB_OBJ_SHAREABLE_P(obj) * rb_ractor_shareable_p(obj) * rb_ractor_std*() * rb_cRactor and rm ractor_pub.h and rename srcdir/ractor.h to srcdir/ractor_core.h (to avoid conflict with include/ruby/ractor.h) Notes: Merged: https://github.com/ruby/ruby/pull/3775
2020-11-11	introduce USE_VM_CLOCK for windows.	Koichi Sasada
	The timer function used on windows system set timer interrupt flag of current main ractor's executing ec and thread can detect the end of time slice. However, to set all ec->interrupt_flag for all running ractors, it is requires to synchronize with other ractors. However, timer thread can not acquire the ractor-wide lock because of some limitation. To solve this issue, this patch introduces USE_VM_CLOCK compile option to introduce rb_vm_t::clock. This clock will be incremented by the timer thread and each thread can check the incrementing by comparison with previous checked clock. At last, on windows platform this patch introduces some overhead, but I think there is no critical performance issue because of this modification. Notes: Merged: https://github.com/ruby/ruby/pull/3754