Toward a better list iterator for the kernel [LWN.net]

Toward a better list iterator for the kernel

Posted Mar 13, 2022 10:08 UTC (Sun) by PengZheng (subscriber, #108006)
In reply to: Toward a better list iterator for the kernel by pankyraghv
Parent article: Toward a better list iterator for the kernel

Thanks for pointing me to SerenityOS. It seems that memory allocation failure will lead to crash:
https://github.com/SerenityOS/serenity/blob/master/AK/Vec...

I assume (it might be false) that C++ exception is not suitable for kernel development and some constrained embedded environment.
Are there any good guidelines for such C++ usages?

to post comments

Toward a better list iterator for the kernel

Posted Mar 13, 2022 11:39 UTC (Sun) by Wol (subscriber, #4433) [Link] (1 responses)

Basically, anywhere you are hardware-constrained (and an OS is a perfect example) you need to be very careful about knowing exactly what abstractions the compiler is using. C++ makes this rather tricky!

Once you're in user space, especially if you're in an online state (ie the computer is a lot faster than the person behind the keyboard), you no longer need to worry and can use the full power of C++. Just make sure you don't use the bits you don't understand :-)

Cheers,
Wol

Toward a better list iterator for the kernel

Posted Mar 14, 2022 2:26 UTC (Mon) by PengZheng (subscriber, #108006) [Link]

Unfortunately, code size will be a concern, even in user space. Nowadays, devices with 64MB flash storage does a lot of things, doubling code-size as mentioned in ianmcc's comment is terrifying.

Toward a better list iterator for the kernel

Posted Mar 13, 2022 15:43 UTC (Sun) by ianmcc (guest, #88379) [Link]

It depends on how exceptions are implemented by the compiler. Exceptions require RTTI, because you need to be able to match the type of the thrown object with a corresponding catch (...) clause. When you have a try {...} block, the compiler needs to know how to unwind the stack. Most modern compilers use a 'zero overhead' model, meaning that the runtime cost (in CPU time) is basically zero for the no-exception case. ie, there is no penalty for having a try {...} block if no exception is actually thrown. The way they do this is with a lookup table from the instruction pointer to the exception handler for the current stack frame. This basically doubles the code size. Also the cost of throwing an exception is quite high, so you normally only want to do it for really exceptional events, not as an alternative to a return statement. But in some cases exceptions can be faster than return codes, i.e. since you need to check the return code every time, in a tight loop using exceptions might be faster.

More info: https://wg21.link/p1947