On Tuesday 25 April 2006 21:22, you wrote:
> Except they can't. Lots and lots of bits of kernel code explicitly
> depend on the fact that certain operations _cannot_ fail, and they
> make that obvious through the fact that those functions don't have
> any way of returning error conditions.
A function declared as
void foo(int bar) throw();
cannot fail or throw.
> >> First of all, that extra TakeLock object chews up stack, at least
> >> 4 or 8 bytes of it, depending on your word size.
> >
> > No, it's optimized out. gcc notices that &lock doesn't change and
> > that 'l' never escapes the function.
>
> GCC does not notice that when you use out-of-line functions. Let me
> remind you that many of the kernel's spinlocks and other functions
> are out-of-line, inlining them has significant performance penalties.
The TakeLock object is completely different from the actual
lock object. The TakeLock object does _only_ call
spin_lock() and spin_unlock(), which are still out of line.
> {
> int result;
> struct foo *item = kmalloc(sizeof(*item), GFP_KERNEL);
> if (unlikely(!item))
> return ERR_PTR(-ENOMEM);
>
> spin_lock(&item_lock);
>
> result = item_init(item, GFP_KERNEL);
scheduling while atomic ;)
> (1) You can't easily allocate and initialize an object in 2
> different steps.
That is not true. Google for "d-pointer" for an example
on how you might do this.
> (2) Your code either adds a refcount for "item" or unconditionally
> releases it at the end of the function. Yes that's fixable, but not
> in a way that preserves the exception-handling properties you're
> espousing so much. When you get an exception, how does the code tell
> which objects to free and which ones not to?
By good design of the exception objects, which carry all needed
information when handling the exception.
I _don't- want to say, that C++ is good in the kernel.
My opinion is: C++ in the kernel is bad.
--
Greetings Michael.
Attachment:
pgpk52nH9Cqh2.pgp
Description: PGP signature
- References:
- Compiling C++ modules
- From: Gary Poppitz <[email protected]>
- Re: Compiling C++ modules
- From: Avi Kivity <[email protected]>
- Re: Compiling C++ modules
- From: Kyle Moffett <[email protected]>
- Compiling C++ modules
- Prev by Date: Re: 2.6.16.6 ( - 2.6.16.11 ) compile failure on an alpha
- Next by Date: [PATCH] Fix coredump vs exec deadlock
- Previous by thread: Re: Compiling C++ modules
- Next by thread: Re: Compiling C++ modules
- Index(es):
 |