>
>
>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.
>
In any C++ port or kernel every part does not have to be written or
rewritten in C++. Don't you already have to allocate space for any object
(C-wise) that you create?
>> 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/