|
On Fri, 4 Nov 2005, Lindbom, Joakim wrote:
midrange.com
Well, if you can guarantee that the processing always takes less than 60
seconds you could do something like
do {
clock1 = now();
...stuff...
clock2 = now();
timeout = 60 - clock2 - clock1;
ReceiveFromDataqueue (myqueue, mydata, timeout); } while (mydata
<> "BREAK")
As you point out, this is flawed if the processing time takes longer than your required timeout. The solution to that is to use fork(). But there is still a flaw. AFAICT, any solution that involves checking how much time has elapsed is flawed because it is subject to drift. Small rounding errors build up or small delays between your time calculation and code execution build up and your timing slowly gets off. That's why using setitimer() looks like the correct way to go. setitimer() uses a kernel timer (at least on linux) which is highly accurate. Even under very high load setitimer() should get the signal from the kernel. Furthermore, there are no rounding errors possible since it always resets itself to the value in it_interval which never changes. And there is no performance penalty since the call to pause() blocks until a signal arrives (i.e. it doesn't poll).
Using the code I posted here yesterday you can handle the problem of code that takes longer to execute than the timeout by simply using a call to fork() in the action() function. This will create a child process that can execute independantly of the timer. Keep in mind that this opens up another possible problem: if your code consistently takes longer to execute than your timer allows you will end up with a "fork bomb" where the number of child processes will grow and grow and grow until they consume the machine! The solution to this new problem is to check how many children the parent has and refuse to create more children if they exceed a certain threshold.
James Rich
It's not the software that's free; it's you.
- billyskank on Groklaw
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
