On Fri, Jun 03, 2011 at 11:15:08AM +0400, Alexey Borzenkov <[email protected]>
wrote:
> don't want to block other coroutines from doing anything useful, they
> need to yield as frequently as they can, and convenient way to do it
> is using sleep(0).
Same as I told Denis - this is basically a shortcoming in the design then.
Why would a thread that does not want to sleep call a sleep function? What if
the semantics of the sleep function change?
> Idle wouldn't do a job here, because if other coroutines are busy with
> network or timers or anything else, idle callbacks won't be called and
> computation will halt.
That is what priorities are for.
> Also, ev_check won't work here, because on the next iteration this
> callback will be
There is also ev_prepare.
> work yet, besides as far as I understand ev_check doesn't influence
> poll timeout.
It's called after the poll, yeah.
> Immediate timers seem to be the only primitive that has
> necessary properties:
Well, depending on what an immediate timer is, it doesn't have the
required properties, while an idle watcher has.
> Currently ev_timer with timeout of 0.0, sadly, doesn't satisfy all
> these properties. However, ev_timer with timeout of -1.0, or any big
> enough negative timeout, does.
No, it doesn't - libev doesn't make guarantees over callback execution,
which is what that does. In fact, ev_timer(-1) will not call any I/O
callbacks before timers are (currently) processed before I/O events.
That's what priorities are for.
Either you want other threads/coroutines to do some work, or you don't. If
you also want to avoid starvation, then you need to combine it with a timer,
which then makes some guaranmtees of how long to let other threads work when
the system is overloaded.
So your design is currently buggy, no matter what you do - all you do
currently is being lucky because most of the time, current libev versions
happen to do almost what you want, and you didn't see the breakage yet.
The fact that you think ev_timer(-1) has these properties shows that there
are design flaws in the system that have nothing to do with ev_timer(0)'s
behaviour, it's just that it has exposed these flaws.
> P.S. Of course the proper way to handle these computations is to use a
> thread pool and offload computation tasks there. It's actually what I
> ended up doing in one of my systems and it works a lot better than
> yielding.
yielding is a way to implement that - it's just that you do not yield
explicitly at convenient points, on some systems the threads run in parallel,
and/or your corotuines are not preemptive but cooperative threads.
but both systems ca do both, so using a thread pool is not right or wrong
- with pthreads you might have to yield explicitly as well.
--
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
