On Wed, Apr 02, 2008 at 01:40:31PM -0600, Tony Arcieri <[EMAIL PROTECTED]>
wrote:
> points into the schedule that would allow for that sort of thing. Ruby 1.9
> uses native threads so it's not an issue... you can make calls that block
> indefinitely with rb_thread_blocking_region().
Ah, so 1.9 is like python with a big interpreter lock so only one "thread"
runs at the same time?
> When adding Ruby 1.8 support to Rev, I used the following approach for a
> "oneshot" style function:
Sounds horrible, let's hope 1.8 obsoletes itself fast :->
> - Loop unless we received events other than the 10ms ev_timer
> - Otherwise rb_funcall the event responders, and return
So basically busy waiting, the worst possible solution.
> impact Ruby 1.8's thread scheduler. However as it is looping making a
> system call every 10ms it does seem to chew up more CPU than I like. I
> haven't played around with making libev block for longer periods of time (I
> think Ebb blocks every 100ms?) but it might be possible to go higher without
> adversely affecting Ruby's thread scheduling.
Well, I don't know much about ruby's versioning, but if it were perl,
then it would only be a matter of time until 1.8 would be obsoleted (in
the sense of: even though many people might use it, it is fine io have
suboptimal solutions for it).
It is not easy (or maybe "obvious") to design a coroutine/thread system
and an event library so one can combine them. Myself I learned a great
deal from the few event systems that allow that, and implementing both a
coroutine/thread scheduler and and even library helped immensely in
understanding the requirements. Everybody should do that :->
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
