On Mon, Feb 15, 2016 at 02:02:34PM +0200, Alex Efros <power...@powerman.name>
wrote:
> On Mon, Feb 15, 2016 at 12:25:19PM +0100, Marc Lehmann wrote:
> > If I run your script, then the reason the timer isn't invoked instantly
> > is simply because it hasn't elapsed yet - try with delay -1 for example,
> > then it will be invoked instantly. For positive delays, it will only be
> > triggered when it's time has elapsed.
>
> But there are no other event watchers, so if this timer hasn't elapsed yet
> when event loop returns then isn't that means event loop returns too early?
How do you know there are no other (for example internal) event watchers?
> Isn't event loop must wait for at least one event if there are active
> watchers when using EV::run(0) and EV::run(RUN_ONCE)?
And as far as I can see, it does that.
> If current behaviour is correct - is it possible to somehow find out is
> RUN_ONCE did something (invoked callback for at least one watcher) or not?
RUN_ONCE always does something, it would block otherwise. If you want to find
out whether specific events (such as your timer) have been invoked, that's
what the callback for your event is for.
So, if you are interested in timer events, when your timer callback is
invoked, then it elapsed, otherwise, something else happened.
> My use case is testing event loop based modules/applications by using
> RUN_ONCE to process and test events one-by-one… and when RUN_ONCE is
> (sometimes) doing nothing
RUN_ONCE always does something - if you wait for specific events to happen
when you test them, you can set a flag in the callback you are waiting for
for example, or don't use RUN_ONCE and use ev_break instead.
> repeat RUN_ONCE, or don't use RUN_ONCE at all and add EV::break to all
> event handlers to emulate it (which isn't ease or even possible for event
> handlers defined outside of test's code).
Well, libev cannot really know which events you are waiting for and
instead returns after any single event. Note that using RUN_ONCE to wait
for specific events likely means you are doing it wrong, so it's best to
use an event-based approach, using callbacks.
You shouldn't test for undocumented behaviour or internals in libev, that
will break sooner or later.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schm...@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev
