Re: unreliable timer with RUN_ONCE since 4.10
On Mon, Feb 22, 2016 at 04:13:07PM +0200, Alex Efros wrote: > Okay, that makes sense, thanks. > > If it works this way (because of internal libev watchers), then I see > possible use cases for EV::run(0) and EV::run(RUN_NOWAIT), but can't > imagine use cases for RUN_ONCE. Are there some examples for RUN_ONCE uses? The typical RUN_ONCE use case is to implement your own ev_run-like function with extra functionality. For example, ev_break-like functionality could be implemented via RUN_ONCE. -- 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
Re: unreliable timer with RUN_ONCE since 4.10
Hi! On Thu, Feb 18, 2016 at 12:51:19PM +0100, Marc Lehmann wrote: > How do you know there are no other (for example internal) event watchers? [cut] > 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. Okay, that makes sense, thanks. If it works this way (because of internal libev watchers), then I see possible use cases for EV::run(0) and EV::run(RUN_NOWAIT), but can't imagine use cases for RUN_ONCE. Are there some examples for RUN_ONCE uses? -- WBR, Alex. ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/mailman/listinfo/libev
Re: unreliable timer with RUN_ONCE since 4.10
On Mon, Feb 15, 2016 at 02:02:34PM +0200, Alex Efros 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
Re: unreliable timer with RUN_ONCE since 4.10
Hi! On Mon, Feb 15, 2016 at 12:25:19PM +0100, Marc Lehmann wrote: > I'm not quite sure what the problem is - RUN_ONCE doesn't wait for > specific events, it simply runs the event loop once, and it seems to work as > it should in your example. > > 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? 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)? 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? 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 I either have to somehow detect this case and 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). -- WBR, Alex. ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/mailman/listinfo/libev
Re: unreliable timer with RUN_ONCE since 4.10
On Sun, Feb 14, 2016 at 06:15:39PM +0200, Alex Efros wrote: > The example is in Perl, but I suppose issue is with libev, not EV. > EV-4.03 doesn't have this issue, EV-4.10 to 4.22 have this issue. > It may be related to improvement for low resolution clock mentioned in > this list for 4.10 (May 2011). > > Problem is: timer for < 1sec doesn't invoked by first RUN_ONCE. I'm not quite sure what the problem is - RUN_ONCE doesn't wait for specific events, it simply runs the event loop once, and it seems to work as it should in your example. 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. > With 0.9 sec versions 4.10-4.22 works unreliably: sometimes timer invoked > by first RUN_ONCE, sometimes not - so I've used 0.1 and 1 sec in this > example. I am not sure why you think it is unreliable - 0.9 means "after 0.9 seconds", not before. -- 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
unreliable timer with RUN_ONCE since 4.10
Hi!
The example is in Perl, but I suppose issue is with libev, not EV.
EV-4.03 doesn't have this issue, EV-4.10 to 4.22 have this issue.
It may be related to improvement for low resolution clock mentioned in
this list for 4.10 (May 2011).
Problem is: timer for < 1sec doesn't invoked by first RUN_ONCE.
$ cat ev-4.10_bug
#!/usr/bin/perl
use EV;
print "EV-$EV::VERSION\n";
my $w = EV::timer $ARGV[0], 0, sub { print "timer\n" };
print "ONE\n";
EV::run(EV::RUN_ONCE);
print "TWO\n";
EV::run(EV::RUN_ONCE);
$ ./ev-4.10_bug 0.1
EV-4.03
ONE
timer
TWO
$ ./ev-4.10_bug 0.1
EV-4.10
ONE
TWO
timer
$ ./ev-4.10_bug 1
EV-4.10
ONE
timer
TWO
With 0.9 sec versions 4.10-4.22 works unreliably: sometimes timer invoked
by first RUN_ONCE, sometimes not - so I've used 0.1 and 1 sec in this
example.
--
WBR, Alex.
___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev
