signals and system calls
Michael Stenner
mstenner at phy.duke.edu
Wed Apr 9 15:01:07 EDT 2003
On Wed, Apr 09, 2003 at 02:40:11PM -0400, Peter Hansen wrote:
> Michael Stenner wrote:
> >
> > Just to be clear, I'm not trying to "use" signals here. They exist,
> > they WILL be sent (when a system shuts down, for example), and I'm
> > just trying to tolerate them in a way that doesn't lose data.
> >
> > So, the bottom line is: what do people recommend?
>
> Don't.
>
> That is, don't try to be incredibly tolerant even in the face of
> system shutdown and signals that kill your program.
>
> Instead, be tolerant of partially written data structures, half-completed
> operations, and so forth.
>
> There is *no* way you can protect against a power outage, and no
> way you can protect against something like "kill -9" anyway, so
> you are trying to achieve an unattainable level of perfection if
> you insist that under other circumstances you *must not* ever
> lose data.
>
> At least with this view, you'll find it much easier to deal with
> the particular nastiness of signals... just my view.
Actually, this is really excellent advice. I have only one minor
quibble: as stated, your argument comes off as a bit extreme. It
seems akin to those argements that often lead security conversations
down that road to "why bother locking the case when a band of ogres
wielding crowbars and soldering irons can ....".
Just because you can't protect against a power outage or kill -9
(which are freak events in a stable and well-managed system) doesn't
mean you shouldn't _try_ to protect against _normal_ events such as
SIGTERM. I take your advice more as "don't put all your eggs in one
basket", which is probably how you meant it anyway :)
I will take the latter part of your advice ("be tolerant of partially
written data structures...") but would still prefer to deal with the
signals if I can.
Thanks,
Michael
--
Michael Stenner Office Phone: 919-660-2513
Duke University, Dept. of Physics mstenner at phy.duke.edu
Box 90305, Durham N.C. 27708-0305
More information about the Python-list
mailing list