On Sun, 17 Sep 2006, Henri Asseily wrote:

You've got a catch-22: If you ALWAYS want the signal to fire on time, then
you should expect unsafe signals.
Just clean up after yourself.
It's hard to clean up after the kind of problems unsafe signals can
cause. For example, imagine the DB client code is in the middle of
updating some global state when the signal fires. That state variable
or structure will be left in an inconsistent state, just waiting for
the next usage to explode. This kind of corruption can be very hard
to recognize - it might not trigger a problem until that state is used
again, likely in a completely different area of your program.

Memory corruption bugs are the very worst kind, in my opinion - I'll
do whatever I have to do to avoid them. Yes, it's unlikely, but
that's actually worse! I'd rather have a bug that happens every time
than one that only happens once a week, or once a month.


Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 7 of 28 | next ›
Discussion Overview
groupdbi-users @
postedSep 15, '06 at 10:15p
activeSep 19, '06 at 2:54p



site design / logo © 2018 Grokbase