From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,UNPARSEABLE_RELAY shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 938A31F4B4 for ; Tue, 5 Jan 2021 02:25:01 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 02631120929; Tue, 5 Jan 2021 11:24:12 +0900 (JST) Received: from xtrwkhkc.outbound-mail.sendgrid.net (xtrwkhkc.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id 32D2E12091D for ; Tue, 5 Jan 2021 11:24:09 +0900 (JST) Received: by filterdrecv-p3iad2-74bd9fb996-6xc4h with SMTP id filterdrecv-p3iad2-74bd9fb996-6xc4h-18-5FF3CDF7-19 2021-01-05 02:24:55.476852922 +0000 UTC m=+2172161.391005682 Received: from herokuapp.com (unknown) by geopod-ismtpd-2-9 (SG) with ESMTP id F8cuQ9ykSja81tUn_Hr-XA for ; Tue, 05 Jan 2021 02:24:55.409 +0000 (UTC) Date: Tue, 05 Jan 2021 02:24:55 +0000 (UTC) From: ko1@atdot.net Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 77830 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Bug X-Redmine-Issue-Id: 15499 X-Redmine-Issue-Author: apolcyn X-Redmine-Issue-Assignee: ko1 X-Redmine-Sender: ko1 X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: =?us-ascii?Q?fVTMYOBjtdvXNcWwrscBhLsHItUXVK5L4mtnq0mdcReNoHk6SvJtvSD9kcLiL8?= =?us-ascii?Q?=2FoV4yJz8gldTL0fpTpJLtjuKNGobZVEYa3gSekr?= =?us-ascii?Q?797zC867zwJCjO+FfDRPi+iYdhfWolOj9Tg6w0p?= =?us-ascii?Q?AdZaJAC8NSdtt7MYZfKww0b073TgiqWjALvvTQA?= =?us-ascii?Q?OTgzOiLCzXdkiPsdoENJ9J=2FZwlhDqFRee=2Fg=3D=3D?= To: ruby-core@ruby-lang.org X-Entity-ID: b/2+PoftWZ6GuOu3b0IycA== X-ML-Name: ruby-core X-Mail-Count: 101923 Subject: [ruby-core:101923] [Ruby master Bug#15499] Breaking behavior on ruby 2.6: rb_thread_call_without_gvl doesn't invoke unblock_function when used on the main thread X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #15499 has been updated by ko1 (Koichi Sasada). ruby -v changed from 2.6.0 to master Status changed from Closed to Assigned Thank you for your report. I can reproduce the issue. ```ruby Thread.new{ Ractor.receive } Ractor.receive ``` It shouldn't be a `Ractor.receive`, but the condition are: * Make two or more threads. * All threads are waiting for some nogvl operation with custom ubf. Maybe because it is by 9e66910b3bd85de32e95cf019ed285a36aecfd9e > We need another native thread to call some unblocking functions > which aren't RUBY_UBF_IO or RUBY_UBF_PROCESS. Instead of a > permanent thread in <= 2.5, we can now rely on the thread cache > feature to perform interrupts. But I can't understand what is the "thread cache feature". I need to investigate more. ---------------------------------------- Bug #15499: Breaking behavior on ruby 2.6: rb_thread_call_without_gvl doesn't invoke unblock_function when used on the main thread https://bugs.ruby-lang.org/issues/15499#change-89769 * Author: apolcyn (alex polcyn) * Status: Assigned * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: master * Backport: 2.4: DONTNEED, 2.5: DONTNEED, 2.6: DONE ---------------------------------------- This issue was noticed when trying to add ruby 2.6 support to the "grpc" ruby gem (this gem is a native C-extension), and was caught by a unit test. There are several APIs on the grpc ruby gem (https://github.com/grpc/grpc/tree/master/src/ruby) that invoke "rb_thread_call_without_gvl" on the current thread, doing a blocking operation in the "without gvl" callback and cancel that blocking operation in the "unblocking function". These APIs work in ruby versions prior to ruby 2.6 (e.g. ruby 2.5), but have problems when used on ruby 2.6 Minimal repro: My system: ``` > lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 9.6 (stretch) Release: 9.6 Codename: stretch > ruby -v ruby 2.6.0p0 (2018-12-25 revision 66547) [x86_64-linux # I installed ruby 2.6.0 with rvm - https://rvm.io/rvm/install > GRPC_CONFIG=dbg gem install grpc --platform ruby # build grpc gem from source with debug symbols ``` ruby script, "repro.rb" that looks like this: ```ruby require 'grpc' ch = GRPC::Core::Channel.new('localhost:1234', {}, :this_channel_is_insecure) ch.watch_connectivity_state(ch.connectivity_state, Time.now + 360) ``` Run "ruby repro.rb" with an interactive shell, and it will hang there. At this point, ctrl^C the process, and it will not terminate. What should happen is this unblocking func should be invoked: https://github.com/grpc/grpc/blob/master/src/ruby/ext/grpc/rb_channel.c#L354, but as seen with logging or debuggers, that unblocking func is never ran. Thus the blocking operation never completes and the main thread is stuck. When the same repro.rb is ran on e.g. ruby 2.5.3 or ruby 2.4.1, the blocking operation is unblocked and the process terminates, as expected, when sending it a SIGINT. Also note that if the blocking operation is put in a background thread, e.g. with this script: ```ruby require 'grpc' th = Thread.new do ch = GRPC::Core::Channel.new('localhost:1234', {}, :this_channel_is_insecure) ch.watch_connectivity_state(ch.connectivity_state, Time.now + 360) end th.join ``` then "unblocking" functions will in fact be invoked upon sending the process a SIGINT, so this looks like a problem specifically with rb_thread_call_without_gvl being used on the main thread. Please let me know and I can provide more details or alternative repro cases. Thanks in advance. -- https://bugs.ruby-lang.org/