[#88240] [Ruby trunk Feature#14759] [PATCH] set M_ARENA_MAX for glibc malloc — sam.saffron@...
Issue #14759 has been updated by sam.saffron (Sam Saffron).
3 messages
2018/08/01
[#88251] Re: [ruby-alerts:8236] failure alert on trunk@P895 (NG (r64134)) — Eric Wong <normalperson@...>
[email protected] wrote:
3 messages
2018/08/01
[#88305] [Ruby trunk Bug#14968] [PATCH] io.c: make all pipes nonblocking by default — normalperson@...
Issue #14968 has been reported by normalperson (Eric Wong).
4 messages
2018/08/06
[#88331] [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — samuel@...
Issue #13618 has been updated by ioquatix (Samuel Williams).
3 messages
2018/08/08
[#88342] [Ruby trunk Feature#14955] [PATCH] gc.c: use MADV_FREE to release most of the heap page body — ko1@...
Issue #14955 has been updated by ko1 (Koichi Sasada).
3 messages
2018/08/08
[#88433] [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — ko1@...
SXNzdWUgIzEzNjE4IGhhcyBiZWVuIHVwZGF0ZWQgYnkga28xIChLb2ljaGkgU2FzYWRhKS4KCgpX
4 messages
2018/08/10
[#88467] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Eric Wong <normalperson@...>
2018/08/14
a28xQGF0ZG90Lm5ldCB3cm90ZToKPiBJc3N1ZSAjMTM2MTggaGFzIGJlZW4gdXBkYXRlZCBieSBr
[#88475] [Ruby trunk Misc#14937] [PATCH] thread_pthread: lazy-spawn timer-thread only on contention — ko1@...
Issue #14937 has been updated by ko1 (Koichi Sasada).
3 messages
2018/08/14
[#88491] Re: [ruby-cvs:71466] k0kubun:r64374 (trunk): test_function.rb: skip running test — Eric Wong <normalperson@...>
[email protected] wrote:
5 messages
2018/08/15
[#88495] Re: [ruby-cvs:71466] k0kubun:r64374 (trunk): test_function.rb: skip running test
— Takashi Kokubun <takashikkbn@...>
2018/08/15
SSBzZWUuIFBsZWFzZSByZW1vdmUgdGhlIHRlc3QgaWYgdGhlIHRlc3QgaXMgdW5uZWNlc3Nhcnku
[#88496] Re: [ruby-cvs:71466] k0kubun:r64374 (trunk): test_function.rb: skip running test
— Eric Wong <normalperson@...>
2018/08/15
Takashi Kokubun <[email protected]> wrote:
[#88523] [Ruby trunk Bug#14999] ConditionVariable doesn't reacquire the Mutex if Thread#kill-ed — eregontp@...
Issue #14999 has been updated by Eregon (Benoit Daloze).
4 messages
2018/08/17
[#88524] Re: [Ruby trunk Bug#14999] ConditionVariable doesn't reacquire the Mutex if Thread#kill-ed
— Eric Wong <normalperson@...>
2018/08/18
[email protected] wrote:
[#88549] [Ruby trunk Bug#14999] ConditionVariable doesn't reacquire the Mutex if Thread#kill-ed — eregontp@...
Issue #14999 has been updated by Eregon (Benoit Daloze).
3 messages
2018/08/19
[#88676] [Ruby trunk Misc#15014] thread.c: use rb_hrtime_scalar for high-resolution time operations — ko1@...
Issue #15014 has been updated by ko1 (Koichi Sasada).
5 messages
2018/08/27
[#88677] Re: [Ruby trunk Misc#15014] thread.c: use rb_hrtime_scalar for high-resolution time operations
— Eric Wong <normalperson@...>
2018/08/27
[email protected] wrote:
[#88678] Re: [Ruby trunk Misc#15014] thread.c: use rb_hrtime_scalar for high-resolution time operations
— Koichi Sasada <ko1@...>
2018/08/27
On 2018/08/27 16:16, Eric Wong wrote:
[#88716] Re: [ruby-dev:43715] [Ruby 1.9 - Bug #595] Fiber ignores ensure clause — Eric Wong <normalperson@...>
Koichi Sasada wrote:
4 messages
2018/08/29
[#88723] [Ruby trunk Bug#15041] [PATCH] cont.c: set th->root_fiber to current fiber at fork — ko1@...
Issue #15041 has been updated by ko1 (Koichi Sasada).
3 messages
2018/08/29
[#88767] [Ruby trunk Bug#15050] GC after forking with fibers crashes — ko1@...
Issue #15050 has been updated by ko1 (Koichi Sasada).
7 messages
2018/08/31
[#88769] Re: [Ruby trunk Bug#15050] GC after forking with fibers crashes
— Eric Wong <normalperson@...>
2018/08/31
Koichi Sasada <[email protected]> wrote:
[#88770] Re: [Ruby trunk Bug#15050] GC after forking with fibers crashes
— Koichi Sasada <ko1@...>
2018/08/31
[#88773] Re: [Ruby trunk Bug#15050] GC after forking with fibers crashes
— Eric Wong <normalperson@...>
2018/08/31
Koichi Sasada <[email protected]> wrote:
[#88774] Re: [ruby-alerts:8955] failure alert on trunk@P895 (NG (r64594)) — Eric Wong <normalperson@...>
[email protected] wrote:
3 messages
2018/08/31
[ruby-core:88486] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
From:
Eric Wong <normalperson@...>
Date:
2018-08-14 18:25:37 UTC
List:
ruby-core #88486
[email protected] wrote: > [email protected] wrote: > > > I am thinking of adding preemption support to this feature for > compatibility with 1.8 > > non-preemptive vs preemptive. > coroutines are non-preemptive. > threads are preemptive. > Are we talking about having the two behaviours in this new feature? "Preemptive" is a minor detail, here. I don't care that much about it; it is a single bit flag we can implement at a later time. > > So this made me think of "Thread::Coro" > > What is the logic behind "Coro"? Short for "Coroutine". > > Other ideas: Thread::CSP or Thread::Sequential (probably too long) > > Does it mean we will have the CSP algebraic operators available? No, so probably "CSP" is not a good name for this. I am not a formal nomenclature person; I make engineering decisions which are ultimately sympathetic to: a) compatibility with existing codebases b) hardware limitations > Reading through this conversation it feels we are dealing with a feature with a lot of concepts incorporated into it. > Can we get a resume of all the functionality we expect to have? It shouldn't be any different than how Ruby threads are currently used. Only creation is different: "Thread.new {}" vs "Thread::Coro.new {}" > Or even feature comparison with other languages. I don't know feature details of other languages well enough to comment. Basically, this is re-introduction of green threads from Ruby 1.8; but I still want to keep benefits of 1.9-2.5 native threads. See my other reply to ko1 in this thread [ruby-core:88484] for pros/cons of both: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/88484 (or <https://public-inbox.org/ruby-core/20180814174702.GA32360@dcvr/>) However, I don't know other languages (Haskell/GHC, Go, Erlang) well enough to describe APIs; but I know they have lightweight threads (M:N) which use less memory than native 1:1 threads. What I don't like about transparent M:N threading is (AFAIK for those languages) they don't give programmers a choice about when to use native vs green. M:N threading is fine when you want parallelism in SMP because timeslices are predictable when your bottleneck is CPU/memory on SMP systems. Implementations of M:N falls down when you want parallelism across multiple filesystems because timeslices become unpredictable. This is a problem for low-end SSDs and HDDs especially, but also network filesystems and USB sticks. Making the Ruby VM transparently aware of multiple filesystems and bottlenecks/characteristics of each mountpoint may be out-of-scope. I'm not aware of any language runtime takes that into account; so we can leave that to the Ruby user. Also, C Ruby generally sucks at taking advantage of SMP because of GVL. However, we are currently great at dealing with parallelism across multiple filesystems because of 1:1 threads. > I believe we must do that kind of documentation to show to the community in a clear way the new ruby async possibilities. > I'm willing to help in planning and developing it. The goal is to make migration/testing easy and minimize rewrite cost. So programmers can gsub(/\bThread\.new\b/, "Thread::Coro.new") in places where only 1:N threads make sense (see [ruby-core:88484]) Unsubscribe: <mailto:[email protected]?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>
