Re^3: making something happen in real time

But I need better resolution than one second.

Oh, sorry, didn't listen carefully. Then use Time::HiRes, which is a core module on newer perls:

perl -we 'use Time::HiRes "time"; print time, "\n";'
[download]

or the gettimeoftheday function from the same module, or (on linux)

perl -we 'defined(syscall 78, ($d = pack "x100"), 0) or die "panic: ge
+ttimeofday failed $!"; ($s, $u) = unpack "l!l!", $d; printf "%d.%06d\
+n", $s, $u;'
[download]

but 156 instead of 78 on solaris, and 116 (untested) instead of 78 on freebsd, (Update:) 96 instead of 78 on linux-x86_64.

Update:

Before every tick, get the current time, and wait whatever time is left till the next tick.
That's essentially what I'm already doing.

My point is that you have to ask for the time before every sleep. I don't see your code, so you might already be doing that. Of course, if you spawn an external process for querying the time, then that's slow, so don't do that.

Comment on Re^3: making something happen in real time Select or Download Code

Replies are listed 'Best First'.
Re^4: making something happen in real time by bcrowell2 (Friar) on Nov 06, 2005 at 22:03 UTC
My point is that you have to ask for the time before every sleep. I don't see your code, so you might already be doing that. Of course, if you spawn an external process for querying the time, then that's slow, so don't do that. I've switched to using Time::HiRes simply for portability, but it doesn't help with the latency issue at all. Starting a process is fast and predictable. The problem is that regardless of which method I use for sleeping, the latency is very long, and is unpredictable.	[reply]
Re^4: making something happen in real time by bcrowell2 (Friar) on Nov 07, 2005 at 02:38 UTC
My point is that you have to ask for the time before every sleep. I don't see your code, so you might already be doing that. I've posted my code. Of course, if you spawn an external process for querying the time, then that's slow, so don't do that. Starting up a new process takes a short, predictable time. (The time to start the external "play" utility and start playing the sound is less than ~1 ms, which is negligible for my purposes.) My problem is latency, which is a long and unpredictable time period, often hundreds of milliseconds before my process gets control back from xscreensaver.	[reply]