[#87773] timer thread [was Re: [ruby-alerts:7905] failure alert on trunk-asserts@silicon-docker (NG (r63844))] — Eric Wong <normalperson@...>
> test_all <main>: warning: pthread_create failed for timer: Resource temporarily unavailable, scheduling broken
[#87836] [Ruby trunk Bug#14898] test/lib/test/unit/parallel.rb: TestSocket#test_timestamp stuck sometimes — ko1@...
Issue #14898 has been reported by ko1 (Koichi Sasada).
ko1@atdot.net wrote:
On 2018/07/06 18:47, Eric Wong wrote:
[#87847] undefined symbol: mjit_init_p — Leam Hall <leamhall@...>
I pulled Ruby trunk on 3 Jul and am now getting errors similar to the
QXMgSSB0b2xkIHlvdSwgYG1ha2UgaW5zdGFsbGAgaXMgbmVlZGVkIHRvIG1ha2UgUnVieSB3b3Jr
T25lIG1vcmUgcmVhc29uIGZvciBodHRwczovL2J1Z3MucnVieS1sYW5nLm9yZy9pc3N1ZXMvMTM2
[#87986] [Ruby trunk Feature#14915] Deprecate String#crypt, move implementation to string/crypt — mame@...
Issue #14915 has been updated by mame (Yusuke Endoh).
mame@ruby-lang.org wrote:
normalperson (Eric Wong) wrote:
[#88088] [Ruby trunk Misc#14937] [PATCH] thread_pthread: lazy-spawn timer-thread only on contention — normalperson@...
Issue #14937 has been reported by normalperson (Eric Wong).
[#88104] [Ruby trunk Bug#14898] test/lib/test/unit/parallel.rb: TestSocket#test_timestamp stuck sometimes — ko1@...
Issue #14898 has been updated by ko1 (Koichi Sasada).
[#88173] [Ruby trunk Bug#14950] r64109 thread.c: move ppoll wrapper before thread_pthread.c - Windows compile failure - thread.c — Greg.mpls@...
Issue #14950 has been reported by MSP-Greg (Greg L).
[#88189] [Ruby trunk Bug#14950] r64109 thread.c: move ppoll wrapper before thread_pthread.c - Windows compile failure - thread.c — nobu@...
Issue #14950 has been updated by nobu (Nobuyoshi Nakada).
[#88199] [Ruby trunk Misc#14937] [PATCH] thread_pthread: lazy-spawn timer-thread only on contention — takashikkbn@...
Issue #14937 has been updated by k0kubun (Takashi Kokubun).
takashikkbn@gmail.com wrote:
> yet, sky3 had a failure at
> http://ci.rvm.jp/results/trunk@P895/1173951
> > http://ci.rvm.jp/results/trunk@P895/1173951
[ruby-core:88151] [Ruby trunk Feature#14717] [PATCH] thread: allow disabling preempt
Issue #14717 has been updated by Eregon (Benoit Daloze).
normalperson (Eric Wong) wrote:
> Giving control to other threads still happens with Thread.pass
> or anything which currently releases GVL (including IO#read,
> File.open, etc...).
At that point I wouldn't call them threads anymore,
I think threads usually imply preemption (not just on blocking actions but also timer-based).
Also, we'd be mixing two very different kinds of Threads, preemptive threads and auto-fibers.
> For platforms without GVL, it can be a no-op. I understand why
> this can be a bad feature from that perspective (I hate GVL, too).
> I mainly wanted this feature to give equivalance for
> proposed auto-Fiber [Feature #13618] behavior.
No, because if it's a no-op it has different semantics.
Other Ruby implementations without GVL will want to support something like auto-fibers too, and have compatible API.
Designing this way seems to make it a MRI/GVL-only feature which is wrong.
However, I think making preemption an argument of the constructor, or a special Thread class/factory method
would help implementing it on Ruby implementations without a GVL.
Still, it's unclear to me how multiple "non-preemptive threads" would work (when there is no GVL).
I think auto-fibers need to be at a different level than Thread, so we can reason about such questions.
Being at Fiber level clarifies this: all fibers of a Thread never execute in parallel, but fibers of different Threads can.
I think it wouldn't make any sense in a Ruby implementation without GVL to have "a running non-preemptive thread/auto-fiber" prevent all other (preemptive) Threads to execute concurrently.
----------------------------------------
Feature #14717: [PATCH] thread: allow disabling preempt
https://bugs.ruby-lang.org/issues/14717#change-73176
* Author: normalperson (Eric Wong)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
----------------------------------------
In some cases, it may be beneficial to disable preemptibility to
have more predictable behavior than increasing Thread#priority.
Threads with preempt disabled will run until they either:
a) encounter a thread blocking region
b) call Thread.pass
This allows native threads to act cooperatively without
being interrupted by other threads.
Thread#preemptible? => true or false
Thread#preemptible = (true|false)
I plan to implement timer-based switching to "auto-fiber/threadlet/thriber/whatever-name"
[Feature #13618] to minimize migration costs from Thread.
However, I think based on the discussion in [Feature #13618]; having
predictability of non-preemptible threads is beneficial. So implement it
for native Thread for now.
I will unify the behavior of [Feature #13618] with existing Thread.
I think green/native threads can be unified under Thread class similar to
how Fixnum/Bignum are both "Integer".
---Files--------------------------------
0001-thread-allow-disabling-preempt.patch (4.16 KB)
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>