[lkml]   [2002]   [Feb]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] [PATCH] C exceptions in kernel
On Sat, 23 Feb 2002, Bill Huey wrote:

> On Sat, Feb 23, 2002 at 07:50:02AM -0500, Pete Zaitcev wrote:
> > Personally, I have no problem handling current practices.
> > But I may see the point of the guy with the try/catch patch.
> > Do not make me to defend him though. I am trying to learn
> > is those exceptions are actually helpful. BTW, we all know
> > where they come from (all of Cutler's NT is written that way),
> > but let it not cloud our judgement.
> Uh, that's probably not right. If I've been told/remember correctly,
> it's a technique that certain old school mainframe OSes use to
> implement sophisticate fault recovery of various sorts. As you know,
> one basically rewinds to the original point before the block is
> called so that you can recover/continue from it.

You can't do that w/out an integrated resource allocation/deallocation
system. This because real code ends up by allocating resources ( or doing
whatever operation that needs an undo ) during its path and if you do not
have an automatic resource deallocation you're going to leak resources
more than Harleys engine oil. So w/out such system you've to catch
exceptions at every level where you actually own resources with the code
that is likely->surely to be way worse than the kernel gotos. Where you're
going to save is in cases where your code does not allocate any resource (
book's code ) and here you save the cost of multiple unwinding 'return's
against a single catch link. So, in case that an exception happen ( very
low probability compared to the common path ) and in case your code
underneath the catch point does not own resources, you're going to have a
'little' advantage. What is the cost ? You're going to push onto the
common path the exception code by slowing down the CPU's fast path.

- Davide

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:20    [W:0.098 / U:1.548 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site