<br><br><div class="gmail_quote">On Thu, Jan 14, 2010 at 11:49 AM, Rob Janes <span dir="ltr">&lt;<a href="mailto:janes.rob@gmail.com">janes.rob@gmail.com</a>&gt;</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&#39;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 &#39;actually&#39;<br>read or written), you might find out that the &#39;whole&#39; buffer wasn&#39;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>