time to bleed by Joe Damato - Latest Comments in Ruby threading bugfix: small fix goes a long way.

Re: Ruby threading bugfix: small fix goes a long way.

rogerpack — Thu, 22 Apr 2010 15:08:02 -0000

Appears the patch has been accepted upstream.
http://blog.phusion.nl/2010...

Re: Ruby threading bugfix: small fix goes a long way.

Georgia Sewall — Tue, 14 Jul 2009 17:57:58 -0000

do you have a thread called "shrinking thread"...happened to see a quilting show on TV...guest was showing a pillow she had covered and one of the swatches was made w/shrinking thread...made the surface look like it was wrinkled....very atractive....

Re: Ruby threading bugfix: small fix goes a long way.

Ian Lesperance — Wed, 04 Feb 2009 23:20:01 -0000

We're using 1.8.5 p115 and are running into this SIGVTALRM weirdness with Phusion Passenger. I tried adapting the patch for 1.8.5 and came up with the following:

http://www.elliterate.com/f...

Any reason why this couldn't work? It doesn't seem to be causing any problems (yet) on our staging server.

Re: Ruby threading bugfix: small fix goes a long way.

Roman — Tue, 09 Dec 2008 10:11:36 -0000

Thanks for the patch, it finally fixed that SIGVTALRM weirdness that I was experiencing. Too bad that I ran in circles trying to understand what I'm doing wrong, when in fact it was a VM bug. But it seems that your fix is not even in the latest 1.8.7 snapshot. Perhaps you need to bug ruby-core again in order to include it.

Re: Ruby threading bugfix: small fix goes a long way.

joe — Sat, 25 Oct 2008 04:39:49 -0000

@roger - This patch has been submit to ruby-core. Also, ruby uses asynchronous blocking I/O.

Stay tuned for a new timetobleed article about different I/O models.

Thanks for reading!

Re: Ruby threading bugfix: small fix goes a long way.

rogerdpack — Fri, 24 Oct 2008 12:53:18 -0000

@hongli the mysqlplus library doesn't block if you use async_query :) [oh wait, you probably already knew that].

MRI 1.8.x does use a "non blocking" internal IO--kind of slow [1] but it works.

I'd say definitely submit a patch to core for this one -- others may benefit :) -- wonder if 1.9 is affected [though know nothing about it].

Maybe somebody should actually buy something from software verify :)

Thanks for doing these.

-=R

[1] http://www.ruby-forum.com/t...

Re: Ruby threading bugfix: small fix goes a long way.

joe — Mon, 06 Oct 2008 13:45:17 -0000

@Hongli Lai: Thanks for the comments - I will try to make my posts more clear in the future.

You are correct that ruby attempts to do non-blocking I/O whenever possible, but it cannot control what the ruby extensions do. So if your ruby extension does blocking I/O, your Ruby process blocks.

I also want to point out that when the actual I/O is occurring (in your example, when there is data for read) that I/O operation WILL block all of Ruby and all green threads.

I plan on writing a blog post or two soon that will talk about different I/O models (blocking vs nonblocking vs async) and I'll touch more on these details there.

Again, thanks for reading and I'll make some corrections to my post to make it more clear.

Re: Ruby threading bugfix: small fix goes a long way.

Jesse — Mon, 06 Oct 2008 12:18:14 -0000

My phone interview question at YouTube was "How would you build a thread scheduler?"

A stupid question for a phone interview (and the interviewer was entirely too please with himself), but I'm interested in seeing the answer from someone who knows what they're talking about, i.e., not me.

Re: Ruby threading bugfix: small fix goes a long way.

Hongli Lai — Mon, 06 Oct 2008 04:33:24 -0000

Nice! Have you considered submitting this patch to upstream?

"What this means for the Ruby developer is that any thread which does I/O will cause the entire ruby process (the ruby interpretter and all ruby green threads) to block."

Sorry, gotta disagree with you here. The MRI core I/O implementation is essentially non-blocking. If it detects that an I/O operation will block, it will simply set the thread's state to 'blocking on I/O' and schedule another green thread instead.

Consider this:
require 'thread'
require 'socket'

thread = Thread.new do
while true
puts rand
sleep 1
end
end

TCPSocket.new('www.google.com', 80).read

Look! The thread keeps running even though we're blocked on a read operation.

What is true however, is that native extensions that:
1. use blocking I/O
and
2. aren't explicitly programmed to support green threads (i.e. to cause a context switch when it detects a potentially blocking condition)
will block all green threads. The MySQL library is one such example.