Re: C++ in kernel (was Re: exception in a device driver)

Alexander Viro (viro@math.psu.edu)
Sat, 16 Jan 1999 01:01:44 -0500 (EST)


On Sat, 16 Jan 1999, Chip Salzenberg wrote:

> According to Oliver Xymoron:
> > On Mon, 11 Jan 1999, Chip Salzenberg wrote:
> > > In C the kernel says e.g. 'return -ENOENT'. That's not 'handling'
> > > the error at all! It's just *reporting* the error.
> > >
> > > Replace the 'return' with a 'throw' in C++, and nothing's different,
> > > except that it's effectively a multi-stack-frame return that's used
> > > to _report_ errors.
> >
> > Not anywhere near that simple. Having exceptions anywhere in the kernel
> > would require protecting basically every critical section with exception
> > handling (much worse than the current small number of spinlocks) to avoid
> > leaving data/hardware/spinlocks in an inconsistent state ...
>
> You're working too hard (or at least proposing that someone _else_
> work too hard). Just follow Stroupstrup's design rule: "Constructors
> acquite resources; destructors release them."

So, you are going to allocate an object in stack for each
semaphore you are holding? Look at the VFS code someday. I've toyed with
similar idea. It can be done both in C++ and in C, but it will give us a
shitload of overhead even if we'll do it in assembler. *If* you are going
to make any kind of record for each semaphore/lock you are going to grab
you'll get a massive overhead simply by fact of doing it. And let's not
get started on spinlocks here.

> Because destructors are automatically called as stacks unwind.

... when there are objects to release.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/