[tpm] fork and blessed hash references

[Rob Janes]

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
> socket
> 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
> processed
> 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.
>
>
>
>