[#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:90887] Re: [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
From:
Eric Wong <normalperson@...>
Date:
2019-01-04 13:20:23 UTC
List:
ruby-core #90887
Eric Wong <normalperson@yhbt.net> wrote:
> apolcyn@google.com wrote:
> > Thanks for the quick look! I didn't get a chance to try out
> > UBF_TIMER=2 before your last comment, but let me know if
> > there's something else to try.
>
> Sorry for the breakage. For now, you can workaround this
> breakage by spawning a do-nothing thread to handle signals:
r66708 should fix the breakage in your particular case.
Again, deeply sorry for the breakage.
> Thread.new { sleep }
>
> I'm slowly working on a permanent fix which won't increase
> overhead for the majority of use cases.
So r66708 uses a short-lived thread and thread-cache to avoid
permanent overhead.
r66712 introduces an experimental new API (rb_nogvl) which
allows C-API users to fire some unblock functions in signal
handlers. It won't affect grpc's case, but it affects zlib and
bignum in core, at least.
It turns out zlib and bignum had the same problem you encountered;
but I missed them.
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>