[tpm] fork and blessed hash references
janes.rob at gmail.com
Thu Jan 14 09:21:06 PST 2010
good advice. this caveat applies to all signals, SIGALRM included.
On Thu, Jan 14, 2010 at 12:13 PM, Fulko Hew <fulko.hew at gmail.com> wrote:
> On Thu, Jan 14, 2010 at 11:49 AM, Rob Janes <janes.rob at gmail.com> wrote:
> ... snip ...
>> there is an alternative process. set a signal handler for one of the
>> user signals SIGUSR1 say. Send a signal to that process and handler
>> to reset the timer. Your SIGALRM handler then is in a process which
>> also has a SIGUSR1 handler. The SIGUSR1 handler resets the timer.
>> This way you don't need shared memory or semaphores. Much easier,
>> much less complicated. All that needs to be known globally is the pid
>> (process id) and maybe the tid (thread id) of the SIGUSR1 handler.
> The caveat for using signals, is that they interrupt whatever might be
> going on,
> which is good, but if you were in the middle of a read or write (like to a
> or a file), the call to read, write, etc. can be interrupted. So if you are
> not looking
> at their return values (which sometimes tells you how much was 'actually'
> read or written), you might find out that the 'whole' buffer wasn't
> and you have to handle that (outstanding) fragment yourself. But thats just
> good programming anyway. But its not normally a condition you need to
> consider... if there is no way your application _could_ get interrupted.
More information about the toronto-pm