Dan Sugalski wrote:

> At 02:48 AM 8/24/00 +0200, Markus Peter wrote:
>
> >--On 23.08.2000 17:26 Uhr -0700 Glenn Linderman wrote:
> >
> >>Thanks for reminding me of this, Bart, if RFC 88 co-opts die for non-fatal
> >>errors, people that want to write fatal errors can switch to using "warn
> >>...; exit ( 250 );" instead of "die ...;" like they do today.  [Tongue
> >>firmly planted on cheek.]
> >
> >I can only hope this is pure irony...

Indeed it was.

> >There is no such thing as an ultimately fatal error - it should always be
> >up  to the user of a module wether the program should die, but I guess you
> >see that the same and will answer me with "use eval" then ;-)
>
> I hope you're speaking from a perl level--a segfault pretty much spells
> "Game Over"...

I have seen and worked on C++ code implementing a database system where database
data was read into pages marked read-only, and then code was run.  When attempts
were made to write to the data, a segment fault was generated, the fault handler
attempted to  obtain a transaction lock on the data for that page.  If it was
successful, it marked the page writable and resumed from the fault.  If it was
unsuccessful in obtaining the lock, it marked the transaction "must be aborted",
and threw a C++ exception out of the signal handler invoked by the segfault.

Just to point out that fatal is, indeed, as several people keep saying, truly in
the eye of the catcher.

That said, none of the currently proposed mechanisms permit "resume from fault"
semantics, much less "resume from hardware fault" semantics.  Sounds like good
RFC fodder to me!

One point of view might hold that "resume from hardware fault" would need only
be implemented by a "fatal error handling" mechanism, and would not be necessary
in a "non-fatal error handling" mechanism.

--
Glenn
=====
There  are two kinds of people, those
who finish  what they start,  and  so
on...                 -- Robert Byrne



____________NetZero Free Internet Access and Email_________
Download Now     http://www.netzero.net/download/index.html
Request a CDROM  1-800-333-3633
___________________________________________________________

Reply via email to