From: charlez.leu@gmail.com
To: ruby-core@ruby-lang.org
Subject: [ruby-core:70903] [Ruby trunk - Bug #11549] [Open] Object allocation during garbage collection phase terminates the Ruby process
Date: Fri, 25 Sep 2015 01:41:12 +0000 [thread overview]
Message-ID: <redmine.issue-11549.20150925014110.32cc7d0c1047afef@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-11549.20150925014110@ruby-lang.org
Issue #11549 has been reported by Charles Leu.
----------------------------------------
Bug #11549: Object allocation during garbage collection phase terminates the Ruby process
https://bugs.ruby-lang.org/issues/11549
* Author: Charles Leu
* Status: Open
* Priority: Normal
* Assignee:
* 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/
next parent reply other threads:[~2015-09-25 1:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <redmine.issue-11549.20150925014110@ruby-lang.org>
2015-09-25 1:41 ` charlez.leu [this message]
2015-09-26 8:12 ` [ruby-core:70918] [Ruby trunk - Bug #11549] Object allocation during garbage collection phase terminates the Ruby process ko1
2015-11-19 7:04 ` [ruby-core:71572] [Ruby trunk - Bug #11549] [Feedback] " ko1
2015-11-24 21:55 ` [ruby-core:71666] [Ruby trunk - Bug #11549] " charlez.leu
2015-11-25 1:35 ` [ruby-core:71670] " ko1
2015-11-25 2:14 ` [ruby-core:71672] " charlez.leu
2015-11-25 2:42 ` [ruby-core:71673] " ko1
2015-11-25 2:42 ` [ruby-core:71674] " ko1
2015-11-25 2:49 ` [ruby-core:71675] " SASADA Koichi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.ruby-lang.org/en/community/mailing-lists/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=redmine.issue-11549.20150925014110.32cc7d0c1047afef@ruby-lang.org \
--to=ruby-core@ruby-lang.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).