Thanks for the replies!

One other 'ruby nasty' I thought of was the fact that sometimes 
functions will end up 'defined' in a different thread than you would 
anticipate them to be.  Like if you do a 'require X' then it loads X -- 
into some other thread.  Very odd.  Anyone ever had any work arounds for 
that?  Any trouble with it?  [The biggest trouble with the things I've 
mentioned is that they are variable--they happen only every so often, 
which makes them tough bugs to stomp out.]

Anyway that's about it!  Thanks again!

-Roger

Jason Roelofs wrote:
> Arg, Francis is just too fast for me. I would also highly recommend
> EventMachine instead of doing your own socket code (it's Francis' 
> library
> :P).
> 
> Also, it seems like you are expecting Ruby threads to be system threads.
> This is simply not the case. Ruby threads are what's called Green 
> threads,
> or handled by the Ruby interpreter only. The OS only ever sees one 
> thread,
> the Ruby process. If you have ~100 Ruby threads going, you are probably
> running out of processing power to handle the constant switching.
> 

So...if they were native threads would anticipate the load not being the 
problem?  I.e. is the only problem with threads inefficiency in context 
switching of Ruby versus an OS?  BTW when I say '100 threads' most of 
them are sleeping or what not, don't worry I'm not insane [or maybe I 
am] :)




> So scale yourself back, if really want to write your own socket code.
> Otherwise go get EventMachine and let it do all the nasty work for you.
> 
> Jason


-- 
Posted via http://www.ruby-forum.com/.