From: Robert Klemme <shortcutter@...>
Date: 2009-10-22T02:35:06+09:00
Subject: Re: ruby 1.8.6, threadpooling and blocking sockets - advice/help

On 21.10.2009 13:49, Daniel Bush wrote:
> Brian Candler wrote:

>> You could try the same approach, and use a ruby Mutex to protect your 
>> socket#accept - but that could turn out to be more expensive than having 
>> a single accept thread which dispatches to your worker pool, if you're 
>> going to have a separate worker pool anyway.
> 
> Yeah, I have a worker pool.  I was sort of extrapolating from that and 
> having an acceptor pool based around the socket in addition to the 
> worker pool.
> 
> I don't have a lot of experience with heavy traffic; but the (naive) 
> motivation for this whole thing was to have one acceptor thread 
> receiving while the other was pushing on the queue and then swapping 
> over and over[1]

You need to synchronize anyway (at least on the queue) so adding another 
synchronization point (at accept) won't gain you much I guess.  As Brian 
said, the effect can be the opposite - and nobody seems to do it anyway. 
  As said, accepting connections is a pretty cheap operation.

> [1] actually, I naively wanted all the threads to block on the socket 
> just like they would on a queue. oh well.

You should also note that the network layer has its own queue at the 
socket (you can control its size as well).  So even if a single thread 
would temporarily not be sufficient connection requests are not 
necessarily rejected.  Basically you have

connect -> [network layer waiting queue] -> accept -> [ruby processing 
queue]

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/