[#81492] [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — normalperson@...
Issue #13618 has been reported by normalperson (Eric Wong).
12 messages
2017/06/01
[#88695] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Eric Wong <normalperson@...>
2018/08/27
> https://bugs.ruby-lang.org/issues/13618
[#81581] [Ruby trunk Bug#13632] Not processable interrupt queue for a thread after it's notified that FD is closed in some other thread. — sir.nickolas@...
Issue #13632 has been reported by nvashchenko (Nikolay Vashchenko).
4 messages
2017/06/05
[#81590] Re: [ruby-cvs:66197] ko1:r59023 (trunk): revert r59020 because it may fail some tests sometimes on some environment (http://ci.rvm.jp/). This revert is to check the reason of failures. — Eric Wong <normalperson@...>
[email protected] wrote:
5 messages
2017/06/06
[#81591] Re: [ruby-cvs:66197] ko1:r59023 (trunk): revert r59020 because it may fail some tests sometimes on some environment (http://ci.rvm.jp/). This revert is to check the reason of failures.
— Eric Wong <normalperson@...>
2017/06/06
Eric Wong <[email protected]> wrote:
[#81596] Re: [ruby-cvs:66203] Re: Re: ko1:r59023 (trunk): revert r59020 because it may fail some tests sometimes on some environment (http://ci.rvm.jp/). This revert is to check the reason of failures.
— Eric Wong <normalperson@...>
2017/06/06
Eric Wong <[email protected]> wrote:
[#81825] [Ruby trunk Feature#13697] [PATCH]: futex based thread primitives — normalperson@...
Issue #13697 has been reported by normalperson (Eric Wong).
3 messages
2017/06/29
[ruby-core:81630] Re: [Ruby trunk Feature#13637] [PATCH] tool/runruby.rb: test with smallest possible machine stack
From:
Eric Wong <normalperson@...>
Date:
2017-06-09 07:40:25 UTC
List:
ruby-core #81630
[email protected] wrote: > I missed this ticket. > I wonder there are no failures on CI. That is fortunate to hear :) > Do you mean that we shouldn't use recursive call which can increase machine stack on `Thread` and `Fiber` in our tests? > Now, we don't have such tests (so that we don't have failures/errors) but it is possible. We should reconsider our code and data structures before introducing recursion in code we control. > I agree that we should consider about machine stack size, but I'm not sure this approach is correct (at least now it seems no problem). Or if we need to introduce such recursive calls, we remove this restriction? If we really need to introduce recursion; we can use assert_separately to test it. However, we should avoid recursion if possible because of GC cost and potential portability + safety problems. Instead; we can redesign data structures and algorithms to avoid recursion (and maybe encourage Rubyists to do the same). Coincidentally, I (finally) announced msgthr earlier on ruby-talk; which makes non-recursive modifications to previously well-known recursive algorithm: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/437984 These were originally implemented in Perl5: Mail::Thread in CPAN: https://rt.cpan.org/Ticket/Display.html?id=116727 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833479 and public-inbox: https://public-inbox.org/meta/[email protected]/t/ Unsubscribe: <mailto:[email protected]?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>