[#61171] Re: [ruby-changes:33145] normal:r45224 (trunk): gc.c: fix build for testing w/o RGenGC — SASADA Koichi <ko1@...>
(2014/03/01 16:15), normal wrote:
[#61243] [ruby-trunk - Feature #9425] [PATCH] st: use power-of-two sizes to avoid slow modulo ops — normalperson@...
Issue #9425 has been updated by Eric Wong.
[#61359] [ruby-trunk - Bug #9609] [Open] [PATCH] vm_eval.c: fix misplaced RB_GC_GUARDs — normalperson@...
Issue #9609 has been reported by Eric Wong.
(2014/03/07 19:09), normalperson@yhbt.net wrote:
SASADA Koichi <ko1@atdot.net> wrote:
[#61424] [REJECT?] xmalloc/xfree: reduce atomic ops w/ thread-locals — Eric Wong <normalperson@...>
I'm unsure about this. I _hate_ the extra branches this adds;
Hi Eric,
SASADA Koichi <ko1@atdot.net> wrote:
(2014/03/14 2:12), Eric Wong wrote:
SASADA Koichi <ko1@atdot.net> wrote:
[#61452] [ruby-trunk - Feature #9632] [Open] [PATCH 0/2] speedup IO#close with linked-list from ccan — normalperson@...
Issue #9632 has been reported by Eric Wong.
[#61496] [ruby-trunk - Feature #9638] [Open] [PATCH] limit IDs to 32-bits on 64-bit systems — normalperson@...
Issue #9638 has been reported by Eric Wong.
[#61568] hash function for global method cache — Eric Wong <normalperson@...>
I came upon this because I noticed existing st numtable worked poorly
(2014/03/18 8:03), Eric Wong wrote:
SASADA Koichi <ko1@atdot.net> wrote:
what's the profit from using binary tree in place of hash?
Юрий Соколов <funny.falcon@gmail.com> wrote:
[#61687] [ruby-trunk - Bug #9606] Ocassional SIGSEGV inTestException#test_machine_stackoverflow on OpenBSD — normalperson@...
Issue #9606 has been updated by Eric Wong.
[#61760] [ruby-trunk - Feature #9632] [PATCH 0/2] speedup IO#close with linked-list from ccan — normalperson@...
Issue #9632 has been updated by Eric Wong.
[ruby-core:61642] [ruby-trunk - Bug #9664] [Open] cannot resume transferred Fiber even if it should resume
Issue #9664 has been reported by Rafał Michalski.
----------------------------------------
Bug #9664: cannot resume transferred Fiber even if it should resume
https://bugs.ruby-lang.org/issues/9664
* Author: Rafał Michalski
* Status: Open
* Priority: High
* Assignee:
* Category:
* Target version:
* ruby -v: 2.1.0 2.0.0-p353
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN
----------------------------------------
The simplified case:
~~~
root = Fiber.current
f = Fiber.new {
puts 'transfer'
root.transfer
puts 'yield'
Fiber.yield
puts 'ok'
}
f.resume
f.transfer
f.resume
~~~
First we resume into a new fiber, then the fiber f transfers control back to root and then root transfers control back to f.
Then the fiber f yields back to root and when root tries to resume fiber f the unexpected error is raised.
In ruby MRI 1.9.(1-3) it works as expected and the result is:
transfer
yield
ok
However since MRI 2.0 we get:
~~~
transfer
yield
-:11:in `resume': cannot resume transferred Fiber (FiberError)
from -:11:in `<main>'
~~~
In ruby #transfer docs one reads:
> The fiber which receives the transfer call is treats it much like a resume call. Arguments passed to transfer are treated like those passed to resume.
>
> You cannot resume a fiber that transferred control to another one. This will cause a double resume error. You need to transfer control back to this fiber before it can yield and resume.
But it looks like since 2.0 you can't yield and resume fiber after transfering control from or back to it.
This looks like if a fiber has ever transfered control with #transfer then it is somehow marked and resuming to it is no more possible.
This bug kills possibility to use e.g. fiber-synchronized async frameworks together with enumerators.
--
https://bugs.ruby-lang.org/