On Thu, Dec 06, 2007 at 01:07:21AM +0100, Jochen Stenzel <[EMAIL PROTECTED]> 
wrote:
> > any signals, and in fatc, I cannot reproduce this. Are you sure that your
> > tty settings actually do anything with CTRL-C (such as sending an INT)?
> 
> I am - I retried it today, other programs receive the signal and the
> effect is the same if I send the signal via kill from another terminal.

Here is what happens on windows btw: at least activestate perl overrides
the system console handler and thus disables those signals. As it doesn't
provide signal emulation for other programs you cnanot catch those signals
anymore, and there is nothing one can do about it. Or to put it in other
words, perl actually emulates those signals in perl without emulating them
in the C level - nothing an event loop can do about that, thats a limitation
of at leats activestate perl.

> I know the following is an incomplete report as it does not contain
> exact system information (in general, Solaris 5.8) and perl version (in

Since there is no solaris 5.8 version in existance, I guess you mean
solaris 8 (that could make a difference as I only test on solaris 10).

> * By the way, there *were* cases today when the signal was ignored
>   completely, this time in a script where I had to add an explicit
>   signal watcher to make it interruptable at all. I hope to shrink
>   this down to a short demo script to send.

Indeed, that would be helpful.

However, are you sure you don't provide your own signal handlers via %SIG
and you really have a signal handler installed for SIGINT? Either would
actually perfectly explain the behaviour you are seeing. %SIG cannot work
because in newer perls this is only handled when the perl interpreter gets
control (which cannot be the case unless you run some watchers). The whole
point of an event loop is to shield you from asynchronous signals, you
have to embed them into the event loop (thats not specific to EV, other
event loops work the same way).

If you cannot install signal handlers properly you could try to install a
check watcher, which runs at every loop iteration, and hope that whoever
installs its own signal handler doesn't make syscalls restartable, in
which case you have lost anyways.

>   DB<2> $p=EV::periodic(0, 2, 0, sub {print "Periodic call with short 
> intervall at ", time, ".\n"})

Here you store one reference into $p, the other is kept by the debugger.

>   DB<<4>> $p=EV::periodic(0, 20, 0, sub {print "Periodic call with > longer 
> intervall at ", time, ".\n"})

> Periodic call with longer intervall at 1196850145.
> Periodic call with short intervall at 1196850145.

Since you only overwrote one reference here, both watchers are still
active.

Watchers only get destroyed when _all_ refererences are broken, as with
any other perl object (the same is true with Event, except that you
additionally need an additional explicit cancel call with Event).

> was no further reference to the first watcher object. But when running
> the loop again *both* watchers were present.

Yup, because both are alive.

Try outside the debugger, that will be less confusing (also, it would help
if you wouldn't wrap codelines in your emails :).

Try e.g.:

   use EV;

   $p=EV::periodic(0, 2, 0, sub {print "Periodic call with short intervall at 
", EV::now, ".\n"});
   $t = EV::timer 3,0,sub { EV::unloop };

   EV::loop;

   $p = EV::periodic(0, 20, 0, sub {print "Periodic call with longer intervall 
at ", EV::now, ".\n"});

   EV::loop;

Here it is easy to see when values get destroyed.

As an additional hint, you should give EV::now a try: it is faster then
time (no syscall) and more accurate in the sense that it returns the event
timestamp (while time returns the current time, which might or might not
be what you are interested in).

> Finally, in both traces one sees a first callback invocation that does
> not fit into the periodic scheme.

That "one" must have rather magical abilities to see anything when you
round your time and do not use the event time but some other time :->
Try using EV::now and you will see that the timestamps are actually
correct. Here are a few sample runs with both EV::now and time to
elaborate this:

   cerebro /tmp# perl x.pl
   Periodic call with short intervall at 1196906694.00098 1196906693.
   Periodic call with longer intervall at 1196906700.00108 1196906699.

   cerebro /tmp# perl x.pl
   Periodic call with short intervall at 1196906706.00513 1196906706.
   Periodic call with short intervall at 1196906708.00117 1196906707.
   Periodic call with longer intervall at 1196906720.00134 1196906719.
   Periodic call with longer intervall at 1196906740.0056 1196906739.

You could alternatively use Time::Hires, which also doesn't round:

   cerebro /tmp# perl x.pl
   Periodic call with short intervall at 1196906782.00217 1196906782.00224.
   Periodic call with short intervall at 1196906784.00219 1196906784.00222.

   cerebro /tmp# perl x.pl
   Periodic call with short intervall at 1196906796.00233 1196906796.00241.
   Periodic call with longer intervall at 1196906800.00238 1196906800.00242.
   Periodic call with longer intervall at 1196906820.00265 1196906820.00268.

In any case, you would see the same behaviour with Event, as it uses
Time::HiRes internally and is therefore also more accurate than time().

> I am not sure when I wil have time to send a demo script for the
> mentioned case of an ignored interrupt but I hope the traces give you a
> first impression.

So far, it seems everything works right. While EV is young and certainly
has some bugs, it is used in a lot of projects, and really can't be
_totally_ broken.

So, when you see totally off behaviour like above, first give your test
script a bit of thinking, and try to find out wether your test actually
can give accurate results (a good example where you should is the time
call and your conclusion that its resolution must be enough to actually
check the scheduling accuracy of EV, while forgetting that its resolution
is very bad indeed).

That keeps adrenaline levels down on all sides :)

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      [EMAIL PROTECTED]
      -=====/_/_//_/\_,_/ /_/\_\

Reply via email to