Christopher Smith wrote:
Yeah, but most often having a second process monitor the first is the
safest and simplest approach for dealing with an unexpected error.
Well, I do have that too, yes. It's also monitoring the hardware, that
processes don't spontaneously exit, and so on.
ensures all the right resources are cleaned up
With a sufficiently introspective language, it's easy to get everything
cleaned up.
and it is easier to code
things so that process death gets things back to a known good (or more
accurately: probably good) state.
There's nothing that keeps you from cleanly exiting a failed process in
a safe language, so I think this is trivial to prove false.
Oh gods this is so not true.... In particular, "safer" languages tend to
be a PITA to deal with when it comes to correcting bugs in the
language's implementation.
Uhhhh, huh? Why is it harder to correct (say) a bug in Tcl than a bug
in GCC? I've even done the former.
(Are you sure you know what a "safe language" means? :-)
--
Darren New / San Diego, CA, USA (PST)
His kernel fu is strong.
He studied at the Shao Linux Temple.
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
