Project

General

Profile

This project is closed and read-only.

Actions

Backport #1484

closed

Ruby 1.8.6_p368 and Ruby 1.8.7_p160 have threading regressions

Backport #1484: Ruby 1.8.6_p368 and Ruby 1.8.7_p160 have threading regressions

Added by hansdegraaff (Hans de Graaff) over 17 years ago. Updated about 7 years ago.

Status:
Closed
Assignee:
-
[ruby-core:23492]

Description

=begin
Changes introduced in ruby 1.8.6_368 and ruby 1.8.7_p160 have regressions in the way they handle threading.

The following bug report for Capistrano details the regression: https://capistrano.lighthouseapp.com/projects/8716/tickets/79-capistrano-hangs-on-shell-command-for-many-computers-on-ruby-186-p368#ticket-79-22

Basically, when trying to deploy to more than one machine capistrano now hangs while eating up all CPU, instead of actually running the deployment tasks. Deploying to a single machine or deploying with e.g. ruby 1.8.7_p72 works fine.
=end


Related issues 1 (0 open — 1 closed)

Has duplicate Backport187 - Bug #1993: IO.select fails when called in multiple threads on 1.8.7p174Closedshyouhei (Shyouhei Urabe)Actions

Updated by rogerdpack (Roger Pack) about 17 years ago Actions #1

=begin

Basically, when trying to deploy to more than one machine capistrano now hangs while eating up all CPU, instead of actually running the deployment tasks. Deploying to a single machine or deploying with e.g. ruby 1.8.7_p72 works fine.

Is this still the case?
=r
=end

Updated by luislavena (Luis Lavena) about 17 years ago Actions #2

=begin
On Wed, Jul 8, 2009 at 5:24 PM, Roger Pack wrote:

Issue #1484 has been updated by Roger Pack.

Basically, when trying to deploy to more than one machine capistrano now hangs while eating up all CPU, instead of actually running the deployment tasks. Deploying to a single machine or deploying with e.g. ruby 1.8.7_p72 works fine.

Is this still the case?
=r

I see similar problems with all threading related tasks on Mongrel and
sqlite3-ruby threaded tests.

Could be a duplicate of the other bug report.

Luis Lavena
AREA 17

Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

=end

Updated by hansdegraaff (Hans de Graaff) about 17 years ago Actions #3

=begin
http://redmine.ruby-lang.org/issues/show/1471 contains some discussion and patches that I thought were successfull, but it seems in my initial testing I was lucky or not careful enough. In any case I'm still seeing this problem with capistrano deployments when deploying to more than one machine at the time.
=end

Updated by dazuma (Daniel Azuma) about 17 years ago Actions #4

=begin
I just reported http://redmine.ruby-lang.org/issues/show/1993 against 1.8.7, which looks like it's the same issue. (Sorry, I should have looked through the bug lists of the other versions-- I had thought this was 1.8.7 specific.) That other report has some analysis of rb_thread_schedule() that I think explains why this is happening. See also http://www.daniel-azuma.com/blog/view/z2ysbx0e4c3it9/ruby_1_8_7_io_select_threading_bug
=end

Updated by hongli (Hongli Lai) about 17 years ago Actions #5

=begin
Hi guys, any updates on this ticket? Has it been fixed yet?
=end

Updated by hansdegraaff (Hans de Graaff) about 17 years ago Actions #6

=begin
As far as I know this has not been fixed yet, but net-ssh-2.0.14 contains a workaround that works with capistrano.
=end

Updated by jeremyevans0 (Jeremy Evans) about 7 years ago Actions #7

  • Tracker changed from Bug to Backport
  • Project changed from 2 to 5
  • Description updated (diff)
  • Status changed from Open to Closed
  • ruby -v deleted (1.8.6_p368, ruby 1.8.7_p160)
Actions

Also available in: PDF Atom