[#80974] [Ruby trunk Feature#13517] [PATCH] reduce rb_mutex_t size from 160 to 80 bytes on 64-bit — ko1@...
Issue #13517 has been updated by ko1 (Koichi Sasada).
4 messages
2017/05/02
[#81024] Re: [Ruby trunk Feature#13517] [PATCH] reduce rb_mutex_t size from 160 to 80 bytes on 64-bit
— SASADA Koichi <ko1@...>
2017/05/07
sorry for late response.
[#80996] [Ruby trunk Feature#13544] Allow loading an ISeqs sequence directly from a C extension without requiring buffer is in an RVALUE — sam.saffron@...
Issue #13544 has been reported by sam.saffron (Sam Saffron).
3 messages
2017/05/04
[#81016] [Ruby trunk Bug#13526] Segmentation fault at 0x0055c2e58e8920 ruby 2.3.1p112 (2016-04-26 revision 54768) [x86_64-linux] — s.wanabe@...
Issue #13526 has been updated by wanabe (_ wanabe).
3 messages
2017/05/07
[#81048] Re: [ruby-cvs:65788] normal:r58614 (trunk): rb_execution_context_t: move stack, stack_size and cfp from rb_thread_t — SASADA Koichi <ko1@...>
It causes compile error on raspi 3.
3 messages
2017/05/09
[#81201] Re: [ruby-cvs:65935] normal:r58761 (trunk): test/test_extilibs.rb: do not check the existence of fiddle — "U.NAKAMURA" <usa@...>
Hi, Eric
4 messages
2017/05/16
[#81202] Re: [ruby-cvs:65935] normal:r58761 (trunk): test/test_extilibs.rb: do not check the existence of fiddle
— Eric Wong <normalperson@...>
2017/05/16
"U.NAKAMURA" <[email protected]> wrote:
[#81427] Fwd: [ruby-changes:46809] normal:r58924 (trunk): test for IO.copy_stream CPU usage (r58534) — SASADA Koichi <ko1@...>
Hi,
6 messages
2017/05/28
[#81428] Re: Fwd: [ruby-changes:46809] normal:r58924 (trunk): test for IO.copy_stream CPU usage (r58534)
— Eric Wong <normalperson@...>
2017/05/28
SASADA Koichi <[email protected]> wrote:
[ruby-core:81025] Re: [Ruby trunk Feature#13517] [PATCH] reduce rb_mutex_t size from 160 to 80 bytes on 64-bit
From:
Eric Wong <normalperson@...>
Date:
2017-05-07 23:08:05 UTC
List:
ruby-core #81025
SASADA Koichi <[email protected]> wrote: > sorry for late response. > I have no objection about this patch. thank you. > > one question. > > ``` > list_for_each_safe(&mutex->waitq, cur, next, node) { > list_del_init(&cur->node); > switch (cur->th->state) { Oops, that should be status, not state: switch (cur->th->status) { > case THREAD_KILLED: > continue; > case THREAD_STOPPED: > case THREAD_RUNNABLE: > case THREAD_STOPPED_FOREVER: > rb_threadptr_interrupt(cur->th); > goto found; > } > } > ``` > `rb_mutex_lock()` set `th->status` as `THREAD_STOPPED_FOREVER` before > native sleep, but the above code quoted from `rb_mutex_unlock_th()`. > > What kind of situation do you assume when the thread status is other > than `THREAD_STOPPED_FOREVER`? Back to your original question. THREAD_RUNNABLE is possible if somebody uses Thread#run: require 'thread' m = Mutex.new th = Thread.new do sleep 0.1 # wait for main thread to get lock m.synchronize do sleep end end m.synchronize do sleep 0.2 # wait for th to block on m.synchronize th.run end I am not sure about other statuses. Maybe exit/GC can trigger THREAD_KILLED, the mutex_free->rb_mutex_unlock_th call chain looks like it might due to GC ordering. Anyways, I will add comments here when I commit. > Thanks, > Koichi Thank you for the review! Unsubscribe: <mailto:[email protected]?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>