[ILUG] Signal handling
blf at blf.utvinternet.co.uk
Wed Dec 8 23:54:41 GMT 2004
sorry Paul, due to an excess of FFW (Fine French Wine),
I hit the wrong keys ... this was meant to go to ILUG.
------- Forwarded Message
To: "Paul Kelly :: Blacknight Solutions" <paul at blacknight.ie>
Subject: Re: [ILUG] Signal handling
| From: "Paul Kelly :: Blacknight Solutions" <paul at blacknight.ie>
| Date: Wed, 8 Dec 2004 08:42:20 -0000
| > I tend to agree, but should point out one issue:
| > killing/restarting something emitting audio will
| > cause a "glitch" in the sound (besides probably
| > restarting it from the beginning), which is not
| > necessarily desirable. whether or not this is
| > Dale's concern is unknown ("a little messy" can
| > mean many things).
| I'm no whiz kid when it comes to programming, but logic would take over at
| this point. When the parent process dies it should ask the child process to
| end cleanly, i.e. have it perform a cleanup/logging operation when the
| parent dies. [ ... ]
not possible in all circumstances.
e.g., kill -9 parent.
or the parent's stack overflowed (so the parent's
signal or atexit(3) hander does not (cannot) run).
the pidfile approach is a common and workable (but
not 100% reliable) answer to the question that was
one logical question is: “is the asked question the
best question to have asked?” (another is, “why is
the parent dying?” at a very crude level, seems to
me that if you fix whatever it is which is causing
the parent to die, the problem becomes tolerable.)
due to the lack of detail, I have been deliberately
steering clear of these (and other) questions, and
concentrating on the questioner's stated, be it odd
and unusual, requirement.
Experienced (20+ years) kernel engineer: | Brian Foster Montpellier,
· Unix, ChorusOS, others; | blf at utvinternet.ie FRANCE
· IDL, automated testing, process, &tc. | Stop E$$o (ExxonMobile)!
Résumé: http://www.blf.utvinternet.ie | http://www.stopesso.com
More information about the ILUG