Delay Return Code

(done in e49758f437c9 bla bla)

Delay would be a code (probably 1 or 2) returned by a handler if it cannot complete the action right now, but could potentially do so in the future. The file would be added to a list, and periodically sniper will check and reexecute that list as if it just saw the item again.

New hotness:

When a handler requests you try again later, just sleep() in the handler process. Then when it wakes up, make sure it slept the full amount, and try to re-execute the handler. Loop will occur.

The biggest problem with this technique is handling signals. The handler cannot wake up after the parent is terminated and do stuff, it must exit WITH the parent. Testing (with http://d.minuslab.net/files/tt.c) has indicated that there is an inconsistent behavior with regard to signals.

  • Signal handlers carry over between parent to child when fork'd. (aka, we must reregister a signal handler for int/term in child)
  • When the parent receives SIGINT (via ctrl-c) it kills both parent and child.
  • When the parent receives SIGINT (via kill -SIGINT) it kills only the parent. (WHAT THE F IS THIS)
  • When the parent recieves SIGTERM (via kill) it kills only the parent.

how the hell to do this?

  • Possible: Check parent pid after waking up in handler, if it is 1, then the parent is dead. (this may not be reliable, can something reparent it?)

Old and busted ideas:

Changes that need to be made to implement:
  * timeout in select.
  * delay list.
  * linked list of pids (of handlers) and files.
    needed for when a handler returns.  check the status in the child reaper, 
    match it up against the item in the list, if its a delay item, add it to
    the delay list.  Note, this could lead to a race condition becuase the child could finish before the parent puts the pid and filename into a linked list.  might need a second linked list in the child reaper to store child pid/return status, then match them up at a later time (timeout values?  alarm?)  Coudl successfully remove an item from the start list and the end list when they both have a pid that matches.  
  * check for mem leak (event struct never freed?)