From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: poffice@blade.nagaokaut.ac.jp Delivered-To: poffice@blade.nagaokaut.ac.jp Received: from kankan.nagaokaut.ac.jp (smtp.nagaokaut.ac.jp [133.44.2.24]) by blade.nagaokaut.ac.jp (Postfix) with ESMTP id 73CC41B8008E for ; Thu, 20 Apr 2017 21:14:20 +0900 (JST) Received: from voscc.nagaokaut.ac.jp (voscc.nagaokaut.ac.jp [133.44.1.100]) by kankan.nagaokaut.ac.jp (Postfix) with ESMTP id 749AEB5D927 for ; Thu, 20 Apr 2017 21:54:35 +0900 (JST) Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by voscc.nagaokaut.ac.jp (Postfix) with ESMTP id BEC5C18CC7ED for ; Thu, 20 Apr 2017 21:54:35 +0900 (JST) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id C96EC12082A; Thu, 20 Apr 2017 21:54:32 +0900 (JST) X-Original-To: ruby-core@ruby-lang.org Delivered-To: ruby-core@ruby-lang.org Received: from o1678916x28.outbound-mail.sendgrid.net (o1678916x28.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id 04520120817 for ; Thu, 20 Apr 2017 21:54:27 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=sendgrid.me; h=from:to:references:subject:mime-version:content-type:content-transfer-encoding:list-id; s=smtpapi; bh=m7JlcU8PVHfVQeZjP0PDSJsk+yQ=; b=S1s+EOMW5qqarkyyg3 3na1r1+82g3RWwMjKzhk/1FawfM6LjCxONloNQ9ipe5EM3SPnY66JbHbMWeQG6YT inWzlt6nCqrFPLVOSGsgjSr1hUn+KrvSKVfAfHakLXyLCwaiiK8CuYvgRYcxTAQc EWGIvJp7rvM8dW+Fh16f39xVY= Received: by filter1118p1mdw1.sendgrid.net with SMTP id filter1118p1mdw1-17379-58F8AF7D-C 2017-04-20 12:54:21.303512297 +0000 UTC Received: from herokuapp.com (ec2-54-159-23-58.compute-1.amazonaws.com [54.159.23.58]) by ismtpd0006p1iad1.sendgrid.net (SG) with ESMTP id c8-LwqntSBqNzdTYT1Wclg for ; Thu, 20 Apr 2017 12:54:21.242 +0000 (UTC) Date: Thu, 20 Apr 2017 12:54:21 +0000 From: magaudet@ca.ibm.com To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 55837 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 13486 X-Redmine-Issue-Author: magaudet X-Redmine-Sender: magaudet 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: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS72r11hxjR8FL3hW8rHV1XAelzWerKtmgB6jT acHM/fpx6uXPADLnob8byhFrf/exBvqBeA1vfNABgZDXWjBOiJjjKxgKyEoTWXngNOyzI0Eoq0aBIl q1QATZNDSUnQPNaTBWxKgQtF5u79e1em2WURCvEtEIwov1cTNxDWb4S7aQ== X-ML-Name: ruby-core X-Mail-Count: 80809 Subject: [ruby-core:80809] [Ruby trunk Misc#13486] Using rb_thread_call_without_gvl{2} 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 #13486 has been updated by magaudet (Matthew Gaudet). Ok. That makes sense. Thanks for the tip. This can probably get closed (I can't seem to do it myself). ---------------------------------------- Misc #13486: Using rb_thread_call_without_gvl{2} https://bugs.ruby-lang.org/issues/13486#change-64407 * Author: magaudet (Matthew Gaudet) * Status: Open * Priority: Normal * Assignee: ---------------------------------------- I'm currently working on adding asynchronous compilation to [Ruby+OMR][1], and I'm trying to use the existing Ruby thread API. However, given that compilation shouldn't happen while holding the GVL, I've been playing with `rb_thread_call_without_gvl{2}`. I've encountered something I don't entirely understand however. It appears that if the unblocking function for a thread is actually invoked, the interpreter hangs on shutdown. With some tracing code elided, it's a pretty simple bit of code: ``` static int compilation_thread_started = 0; void unblock_compilation_thread(void* arg) { *(int*)arg = 0; // interrupt compilation thread. } void* vm_compile_thread(void *vm) { while (compilation_thread_started) { // compile until interupted. rb_thread_wait_for(rb_time_interval(DBL2NUM(0.01))); // pretend to compile by sleeping. } return NULL; } VALUE releaseGVLandStartCompilationThread(rb_vm_t* vm) { compilation_thread_started = 1; rb_thread_call_without_gvl2(vm_compile_thread, /* func */ (void*)vm, /* func arg */ unblock_compilation_thread, /* unblock func */ &compilation_thread_started); /* unblock arg */ return Qnil; } void kickoff_thread(rb_vm_t* vm) { typedef VALUE (*thread_function)(ANYARGS); rb_thread_create((thread_function)(releaseGVLandStartCompilationThread),vm); } ``` I've attached a patch with a very simple reproducing test case that should apply to trunk as of today. If you run it, what you'll notice is that the unblock function runs, the thread code exits and then the interpreter hangs; in an interpreter, what I see is the spawned thread that released the GVL is waiting to re-aquire, but it appears to be held. The main thread on the other hand, is waiting for the final non-main thread to shut down before proceeding with shutdown. I've marked this as Misc, because I'm not entirely sure this isn't user error, but I'd love some guidance on how to spawn a thread that's not holding the GVL, but also have it participate in cleanup actions like regular threads. [1]: https://github.com/rubyomr-preview/ruby/issues/30 ---Files-------------------------------- gvl_thread_error.patch (3.29 KB) -- https://bugs.ruby-lang.org/