[Click] C++ vs the kernel

[Roman Chertov]

Adam M wrote:
> On Tue, 24 Jul 2007 13:05:50 -0700, "Eddie Kohler" <kohler at cs.ucla.edu>
> said:
>> Click code is compiled with -fno-exceptions.  So if you try to use 
>> exceptions I would hope the compiler would complain.
> 
> What do you do if a constructor fails? Do you have to resort to
> initializing objects post-construction?

I think most elements implement a configure function.  This is where you 
can fail the creation of your element and then things will exit 
gracefully.  If you really want to use some intermediate classes that 
are non-"elements", then you can always create a class factory which 
will return NULL pointers if the creation fails.

> 
> 
>> Obviously one can overload operator new() with arguments that provide 
>> info about interrupt context.
>>
>> I'm sure there are bugs re: allocation in Click.  However Click almost 
>> always runs in non-interrupt context; and should not allocate memory in 
>> interrupt context.
> 
> The phrase "almost always" disturbs me a little bit. When would the
> "almost" be violated? Is that something that the Element implementer has
> complete control of? (Again, I'm not much of a kernel developer, so my
> questions may be naive).

The issue with memory allocation in Linux is very problematic during 
interrupts if you are holding locks.  This especially applies to 
spin_locks. (I found that out the hard way).  However, if you are 
operating in kernel memory only and use the proper locking primitives 
then it is my understanding that kalloc should work without issues.  Or 
you can always allocate while you are not in a critical section.

Roman

> 
> 
> Thanks again,
> Adam
>