<br><br><div class="gmail_quote">On Thu, Jan 14, 2010 at 11:49 AM, Rob Janes <span dir="ltr"><<a href="mailto:janes.rob@gmail.com">janes.rob@gmail.com</a>></span> wrote:<br><div>... snip ...<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
there is an alternative process. set a signal handler for one of the<br>
user signals SIGUSR1 say. Send a signal to that process and handler<br>
to reset the timer. Your SIGALRM handler then is in a process which<br>
also has a SIGUSR1 handler. The SIGUSR1 handler resets the timer.<br>
This way you don't need shared memory or semaphores. Much easier,<br>
much less complicated. All that needs to be known globally is the pid<br>
(process id) and maybe the tid (thread id) of the SIGUSR1 handler.<br></blockquote><div><br>The caveat for using signals, is that they interrupt whatever might be going on,<br>which is good, but if you were in the middle of a read or write (like to a socket<br>
or a file), the call to read, write, etc. can be interrupted. So if you are not looking<br>at their return values (which sometimes tells you how much was 'actually'<br>read or written), you might find out that the 'whole' buffer wasn't processed<br>
and you have to handle that (outstanding) fragment yourself. But thats just<br>good programming anyway. But its not normally a condition you need to<br>consider... if there is no way your application _could_ get interrupted.<br>
<br><br></div></div><br>