Hi Everyone,

I figured out this weekend that Ruby's Thread implementation causes the Ruby/Event binding I wrote to completely stall and go dead.  After reviewing the Ruby source and watching several strace runs, it's clear that the Ruby Thread implementation uses select in a way that--while not being bad--just isn't compatible with libevent.  The second a thread is created Ruby assumes it's the only game in town and doesn't relinquish control.

This basically means that, I have three choices as I see it:

	1)  Ruby/Event becomes completely evil and redefines Thread's initialize so that it throws an exception telling you to not use threads.  Ugh.
	2)  Implement DRb using Myriad so that  people can get the advantages of threads without using them.  Also ugh.  No protocol specs does not make for a fun time implementing a protocol.  And no, source code is *not* a protocol specification.
	3)  Abandon Ruby/Event entirely and just base a new implementation of Myriad on the Ruby thread stuff.  I know you purists will think this is great, but you do realize that I get *incredible* performance from libevent and that a pure Ruby implementation would only handle as many connections as select supports (which is sometimes 256)?

I'm writing to get people's feedback on the usefulness of Ruby/Event and Myriad.  Take a look at the project:

http://www.zedshaw.com/projects/ruby_event/

I'm seriously leaning toward just dumping the whole thing, implementing a simple SCGI setup in pure Ruby since that's the most useful part, and then working on FastCST again.

Tell me if, given this new information, you think Myriad and/or the Ruby/Event bindings would still be useful.  Also if you'd accept one of the above options.

Thanks for your time and your opinion.

Zed A. Shaw
http://www.zedshaw.com/