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 (kankan.nagaokaut.ac.jp [133.44.2.24]) by blade.nagaokaut.ac.jp (Postfix) with ESMTP id B6E4019C000E for ; Sat, 26 Sep 2015 16:48:56 +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 A026BB5D860 for ; Sat, 26 Sep 2015 17:12:41 +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 A2B71952439 for ; Sat, 26 Sep 2015 17:12:41 +0900 (JST) Received: from [221.186.184.76] (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 120A9120704; Sat, 26 Sep 2015 17:12:40 +0900 (JST) X-Original-To: ruby-core@ruby-lang.org Delivered-To: ruby-core@ruby-lang.org Received: from o2.heroku.sendgrid.net (o2.heroku.sendgrid.net [67.228.50.55]) by neon.ruby-lang.org (Postfix) with ESMTPS id 5C16D120686 for ; Sat, 26 Sep 2015 17:12:36 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.me; h=from:to:references:subject:mime-version:content-type:content-transfer-encoding:list-id; s=smtpapi; bh=xGO0OXJ4X11PPCHUuiNWzwR4myI=; b=S2jfQ22ANVzvKHJraV Y+ZO/jE03y+caGnDQDpM5qf1DvCRj/fqTOLl5WvkE5V124mliiiMPyyzATugx5kx OC5O4Wts7VhNii1lyEI74KT/UxWZy0Bvn8PSGFm3/fkNpvnKgilv5G8qOrBglDlS 6Cg5Tl+TV+FYz4Wzx0pyorsD8= Received: by filter0480p1mdw1.sendgrid.net with SMTP id filter0480p1mdw1.7460.560653349 2015-09-26 08:11:32.075448347 +0000 UTC Received: from herokuapp.com (ec2-54-234-28-25.compute-1.amazonaws.com [54.234.28.25]) by ismtpd0003p1iad1.sendgrid.net (SG) with ESMTP id Vlyj-g95ROGeYbY2TNy8AA for ; Sat, 26 Sep 2015 08:12:31.134 +0000 (UTC) Date: Sat, 26 Sep 2015 08:12:31 +0000 From: ko1@atdot.net To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Redmine-MailingListIntegration-Message-Ids: 45524 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 11549 X-Redmine-Issue-Author: charlez 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: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS5xqoJPrLq/Ay55Tjx9N3ukUS9ctjFL46yWKi eszcl4hk3IkCMrnnV264SKrs5CWvywhrq9E9HTZTrPEG2F6g79NmuCHaQQ0k8SrrLceyd2ImkQfRMe 6eUnpWzK+rrL3kg= X-ML-Name: ruby-core X-Mail-Count: 70918 Subject: [ruby-core:70918] [Ruby trunk - Bug #11549] Object allocation during garbage collection phase terminates the Ruby process 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: , Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #11549 has been updated by Koichi Sasada. Assignee set to Koichi Sasada ---------------------------------------- Bug #11549: Object allocation during garbage collection phase terminates the Ruby process https://bugs.ruby-lang.org/issues/11549#change-54281 * Author: Charles Leu * Status: Open * Priority: Normal * Assignee: Koichi Sasada * ruby -v: ruby 2.2.3p173 (2015-08-18 revision 51636) [x86_64-linux] * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN ---------------------------------------- Multi-Threaded Ruby apps are often problematic; especially so when utilizing thread pools, and scheduling work to worker threads. RE: attached file ruby_2.2.3_obj_alloc_gc_bug.txt Following is the section of sap_consumer_control.rb that is presented by the Ruby interpreter as being the current execution context when the problem occurs. 408: loop do 409: @worker_threads.schedule(@work_queue.pop, &@consumer) 410: @sap_packets_consumed += 1 411: end Notes: * @work_queue is a Ruby Queue (allocated within the main thread) into which a producer thread places work requests. * @worker_threads is a thread pool (allocated within the main thread). * @worker_threads schedule method simply puts a work request into the thread pool's internal work queue. One of the worker threads within the thread pool will consume/effect the work request, by executing the specified consumer Proc. * The main program thread simply loops forever scheduling work to thread pool threads. * It appears that an object is being allocated by virtue of the @work_queue.pop Questions: * Does Ruby garbage collection potentially run within each thread context? * If answer to prior question is 'Yes', then how can object allocation be prevented when a sibling thread is attempting garbage collection? * How does one write multi-threaded Ruby apps on multi-core systems that permit multiple-concurrent execution contexts that don't employ a mutex to effectively single thread the entire app? ---Files-------------------------------- ruby_2.2.3_obj_alloc_gc_bug.txt (49.1 KB) -- https://bugs.ruby-lang.org/