> Revactor already provides the glue for using Fibers on top of Rev,
> and also bundles a version of Mongrel which uses Actors/Fibers for
> concurrency instead of threads.
Nice. Thanks for doing that! So it''s a single threaded mongrel, like
the evented version?
I assume all the fibers still block in DB calls?
This being the case then perhaps ramaze/merb + sequel using an evented
database would yield a non IO-blocking, single threaded server?
>
> Just install Revactor and require ''revactor/mongrel''
>
> using fibers
>
> def action_1 # this is run within a fiber
> @schools = DB.run ''select * from schools'' # the fiber
yields until
> the DB call comes back, then it resumes
> @locations = @schools[0] # same as above
> render
> end
>
> Yes, you could definitely do something like that with Revactor,
> particularly since it already handles scheduling fibers based on I/O
> events, and provides a routine for you to call to suspend the
> current Fiber until an I/O event occurs.
Nice.
>
>
> Questions:
> Do you think would fibers be ''significantly slower''?
>
> It''s been fast for me. According to my benchmarks I''m
able to task
> switch between 50,000 fibers per second with Revactor acting as the
> scheduler, so that includes message processing, matching, and
> dispatch.
creation speed is trivial, I''d guess, too?
If I got into it too much I wonder if file descriptor support for
reading/writing would be nice :) [or if it typically would be useless
since you can read them pretty fast).
>
> Does an evented DB driver in Ruby stand a chance speed-wise to the
> ''real'' C versions? I guess it would be possible to write
one in C to
> complement rev, but that would be a future optimization.
> My goal really is speed. Trying to go for unbelievable speed, here :)
>
> I think on Rubinius or MagLev they certainly would, but both of
> these likely mitigate the need for an evented driver in the first
> place as they''re fundamentally "evented" at the
scheduler level
> (e.g. Rubinius uses libev for its scheduler)
I suppose that''s if the interpreter were lightning fast. Which I
guess could be the case sometime once maglev gets released or rubinius
gets their act together.
> That said on MRI/YARV I''d expect database interaction done in Ruby
> to be slower than the C counterparts. However it might be possible
> to coerce evented behavior out of the C libraries... I''d have to
> check the APIs.
A quick google search reveals that asynchronous mysql clients seem
pretty rare :)
Perhaps a ruby version [like that noted in the EM list recently] is a
nice first shot at it though.
Thanks for the speedy response!
-R