Rails - Sep 2005 - [RFC] The Early Demise of Myriad (Thanks To Ruby Threads)

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/

Personally I think a ruby event framework is very useful, but without 
threads I don''t know, it''s a lot more limited. Thread pools
are a good way
to manage things like a database connection pool. I use Python''s
twisted
framework quite a bit, and I still find threads very useful within an event 
framework for things like database connection pools. 

My vote would be to put the effort into getting someone to fix the 
underlying issue in the core of ruby, and if that isn''t possible I
would
probably just drop it for now. Without threads I just don''t see a ruby
event
framework getting any real use.

Chris


_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

On 9/11/05, Zed A. Shaw <zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org>
wrote:
> 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.
While I haven''t had a reason to use Ruby/Event yet, I''m ver
interested
in it and might find a use for it real soon now. So, two things: first
of all, I''ve found implementing a DRb protocol to be really easy and
intuitive, even without docs (see
http://rubyforge.org/projects/drbfire). Secondly, please do bring this
up on the ruby-core mailing list, and see if the core Ruby hackers
have any ideas for how to resolve the problem.

Thanks for the great library!


-- 
Nathaniel Talbott

<:((><

ugh.  scgi being the ''replacer for fcgi'' better not be written
in pure
ruby... or i will never use it.

dont give up so easily.  id personally email the ruby maintainers, and
see if you cant maintain the current Thread functionality and modify
it to work with the event library.  im sure this could only make ruby
better.


On 9/12/05, Nathaniel Talbott
<ntalbott-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On 9/11/05, Zed A. Shaw
<zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org> wrote:
> 
> > 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.
> 
> While I haven''t had a reason to use Ruby/Event yet, I''m
ver interested
> in it and might find a use for it real soon now. So, two things: first
> of all, I''ve found implementing a DRb protocol to be really easy
and
> intuitive, even without docs (see
> http://rubyforge.org/projects/drbfire). Secondly, please do bring this
> up on the ruby-core mailing list, and see if the core Ruby hackers
> have any ideas for how to resolve the problem.
> 
> Thanks for the great library!
> 
> 
> --
> Nathaniel Talbott
> 
> <:((><
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
> 

-- 
Zachery Hostens <zacheryph-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

On 9/15/05, Zachery Hostens
<zacheryph-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> ugh.  scgi being the ''replacer for fcgi'' better not be
written in pure
> ruby... or i will never use it.
I''ve been using the pure ruby implementation, performance is still
quite good (comparable to FastCGI). Give it a try before discounting
it.

Ben