[#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).
[#88251] Re: [ruby-alerts:8236] failure alert on trunk@P895 (NG (r64134)) — Eric Wong <normalperson@...>
ko1c-failure@atdot.net wrote:
[#88305] [Ruby trunk Bug#14968] [PATCH] io.c: make all pipes nonblocking by default — normalperson@...
Issue #14968 has been reported by normalperson (Eric Wong).
[#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).
[#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).
[#88433] [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — ko1@...
Issue #13618 has been updated by ko1 (Koichi Sasada).
ko1@atdot.net wrote:
[#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).
[#88491] Re: [ruby-cvs:71466] k0kubun:r64374 (trunk): test_function.rb: skip running test — Eric Wong <normalperson@...>
k0kubun@ruby-lang.org wrote:
I see. Please remove the test if the test is unnecessary.
Takashi Kokubun <takashikkbn@gmail.com> 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).
eregontp@gmail.com 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).
[#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).
ko1@atdot.net wrote:
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:
[#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).
[#88767] [Ruby trunk Bug#15050] GC after forking with fibers crashes — ko1@...
Issue #15050 has been updated by ko1 (Koichi Sasada).
Koichi Sasada <ko1@atdot.net> wrote:
[#88774] Re: [ruby-alerts:8955] failure alert on trunk@P895 (NG (r64594)) — Eric Wong <normalperson@...>
ko1c-failure@atdot.net wrote:
[ruby-core:88467] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
ko1@atdot.net wrote:
> Issue #13618 has been updated by ko1 (Koichi Sasada).
>
>
> We discussed about naming.
>
> ```
> X IoThread.new{}
> X GreenThread.new{}
> X Thread::Green.new{} #124 “most likely candidates”(vote: hsbt)
> X Thread.green{} #124 “most likely candidates”
> X Thread.create(scheduler: …, args: ...) #124 “most likely candidates”
> Thread::Coop.new{}
> Thread::Cooperative.new{} # (usa)
> Thread::Nonpreemptive.new{} # (usa; these 2 names are very long, then they are good ^^)
Huh? Why is a long name good? Long names waste screen space
and increase typo errors.
> X NonpreemptiveThread.new {} # (mrkn)
> X NPThread.new {} # (mrkn)
> X Thread::Light (ko1)
Another option: Thread::Coro.new {}
> ```
>
> X: rejected.
>
> Discussion is follow:
> * (1) At first, "green" is rejected because "green" is how to
> implement and there are several "green threads" can support
> preemption (such as Ruby 1.8).
I am thinking of adding preemption support to this feature for
compatibility with 1.8
> * (2) New toplevel name is rejected because is should be under `Thread` naming.
OK. Otherwise, I would push for "Threadlet" name.
> * (3)`Thread.create` is rejected because it seems to make
> `Thread` class object and auto-fiber should be different
> class.
OK
> * (4) Cooperative is rejected because it is also ambiguous.
I don't think it's ambiguous, but too long.
> * (5) Nonpreemptive is considerable because it is different
> from what the application programmers (users) want.
Right; and again, I think preemptible can be an option.
> * (6) Thread::Light is rejected because this name does not
> make sense what the class is.
Probably, yes.
> I think auto-fibers are Threads which have special attribute (scheduler).
> auto-fibers should have same methods in `Thread`.
> I'm not sure why Matz does not like this idea, though.
Agreed, I want to maximize compatibility with code written for
Ruby 1.8, but cost too much memory to run with Ruby 1.9/2.x
> There are several similar examples:
>
> * Proc (proc and lambda)
> * Fiber (semi-coroutine and coroutine (after `Fiber#transfer`)
So this made me think of "Thread::Coro"
Other ideas: Thread::CSP or Thread::Sequential (probably too long)
https://en.wikipedia.org/wiki/Coroutine
https://en.wikipedia.org/wiki/Communicating_sequential_processes
> Weak examples:
> * Hash (compare_by_identity)
> * Struct (keyword_init)
> * Enumerator (support size or not)
Maybe "Thread.sequential {}" is OK.
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>