[#90865] [Ruby trunk Bug#15499] Breaking behavior on ruby 2.6: rb_thread_call_without_gvl doesn't invoke unblock_function when used on the main thread — apolcyn@...
Issue #15499 has been reported by apolcyn (alex polcyn).
3 messages
2019/01/03
[#90877] [Ruby trunk Bug#15499] Breaking behavior on ruby 2.6: rb_thread_call_without_gvl doesn't invoke unblock_function when used on the main thread — apolcyn@...
Issue #15499 has been updated by apolcyn (alex polcyn).
3 messages
2019/01/03
[#90895] Re: [ruby-alerts:11680] failure alert on trunk-mjit@silicon-docker (NG (r66707)) — Eric Wong <normalperson@...>
ko1c-failure@atdot.net wrote:
4 messages
2019/01/05
[#90896] Re: [ruby-alerts:11680] failure alert on trunk-mjit@silicon-docker (NG (r66707))
— Takashi Kokubun <takashikkbn@...>
2019/01/05
Thanks to explain that.
[#91200] [Ruby trunk Feature#15553] Addrinfo.getaddrinfo supports timeout — glass.saga@...
Issue #15553 has been reported by Glass_saga (Masaki Matsushita).
4 messages
2019/01/21
[#91289] Re: [Ruby trunk Feature#15553] Addrinfo.getaddrinfo supports timeout
— Eric Wong <normalperson@...>
2019/01/26
glass.saga@gmail.com wrote:
[ruby-core:90907] [Ruby trunk Misc#15510] Easter egg in Thread.handle_interrupt
From:
eregontp@...
Date:
2019-01-05 23:53:48 UTC
List:
ruby-core #90907
Issue #15510 has been updated by Eregon (Benoit Daloze). `Integer` sure feels like a hack, but using `Thread.handle_interrupt(Object => :TimingSymbol)` makes some sense, and I think we should document that as a way to also ignore those interrupts. I'm against 1) (no need to be implementation-specific here), and I think 2) with `Object` or a variant (e.g., a Symbol :all) would be good. Specs for Thread.handle_interrupt would be nice to have in ruby/spec, contributions welcome! ---------------------------------------- Misc #15510: Easter egg in Thread.handle_interrupt https://bugs.ruby-lang.org/issues/15510#change-76087 * Author: larskanis (Lars Kanis) * Status: Open * Priority: Normal * Assignee: ---------------------------------------- The docs of `Thread.handle_interrupt` are quite clear about the argument to be passed. It must be a hash of `ExceptionClass => :TimingSymbol` pairs. I never thought that anything other than a `Exception` derivation would be accepted. But then I read the tests to this method and wondered: [Some of the tests](https://github.com/ruby/ruby/blob/trunk/test/ruby/test_thread.rb#L783) set `Object` as `ExceptionClass`. Moreover the method is not covered by ruby-spec and JRuby [excludes several failing tests](https://github.com/jruby/jruby/blob/66d2905ae233a39e36fcbe3ade6382c2892ade8e/test/mri/excludes/TestThread.rb). So I inspected the code and found some obscure behavior: There are actually [two non-exceptions](https://github.com/ruby/ruby/blob/trunk/thread.c#L115-L116) which can be masked by `Thread.handle_interrupt(Integer => :TimingSymbol)`. It is main thread termination and `Thread#kill`. Now this [blur sentence in the docs](https://github.com/ruby/ruby/blob/trunk/thread.c#L1891-L1894) makes some more sense: > interrupt means asynchronous event and corresponding procedure by Thread#raise, Thread#kill, signal trap (not supported yet) and main thread termination (if main thread terminates, then all other thread will be killed). So they are implemented as integers internally. However IMHO `Thread.handle_interrupt(Integer => :TimingSymbol)` is ... ugly. Some proposals are: 1. Make non-exceptions an ruby implementation specific feature, adjusts current tests and optionally add tests which are tagged as implementation specific. 2. Document it officially, but choose some more meaningful class names instead of `Integer` -- 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>