Scope-Based Resource Management Infrastructure Merged For Linux 6.5

[phoronix]

Phoronix: Scope-Based Resource Management Infrastructure Merged For Linux 6.5

Here comes a very exciting addition to the Linux 6.5 kernel: the initial infrastructure has landed for scope-based resource management...

https://www.phoronix.com/news/Linux-6.5-Scope-Resource-Manage

[patrick1946]

That smells a lot like C++. I hope Linus is blocking it and rewriting the code in Rust. 😚

[andyprough]

This is RAII stuff, right? Would this mean that GNU/Linux would get better at fully releasing remaining resources like memory, files, sockets, etc at program termination? Especially in multi-process applications? Because that would be a good thing. A much needed good thing.

[Sethox]

That smells a lot like C++. I hope Linus is blocking it and rewriting the code in Rust. 😚

You joke but someone enthusiastic enough will rewrite it to rust and then get blocked because the programmer isn't proficient enough in it's explanation or coding structure (another revision for it's acceptance). That's usually the case..

[Alpha64]

This is RAII stuff, right? Would this mean that GNU/Linux would get better at fully releasing remaining resources like memory, files, sockets, etc at program termination? Especially in multi-process applications? Because that would be a good thing. A much needed good thing.

The Linux kernel already cleans up after a userspace program ends by freeing all allocated memory (heap and stack) and closing any still-open file descriptors - which includes sockets. This is one of the many services the kernel provides to userspace.

This change is specific to the behavior of things like drivers in kernelspace itself.

[coder]

That smells a lot like C++.

At first glance, it sounds exactly how variables behave in C++.

What I don't know is whether/how it interacts with goto, which could pose a hazard. I'd assume the GCC folks have sorted that out, otherwise it could cause more problems than it solves.

I happen to think destructors and exceptions are two key features making C++ an excellent systems programming language. It's a good call for the kernel to take up at least one of these. Vastly overdue, but better later than never.

BTW, the docs specify that it works only with non-static function-scoped variables. That means it shouldn't be applicable to individual struct members (not surprisingly). Therefore, not fully equivalent to what you can do with destructors in C++.

https://gcc.gnu.org/onlinedocs/gcc/C...able-attribute

[coder]

This is RAII stuff, right?

Yes. It's a prerequisite to using the Resource Acquisition Is Initialization pattern.

Would this mean that GNU/Linux would get better at fully releasing remaining resources like memory, files, sockets, etc at program termination?

As Alpha64 said, it's kernel rather than userspace processes (which are already catered for). I'd just add that it's also very fine-grained. So, resources can literally be tied to a function scope and released when the function returns.

It's great for avoiding dangling locks and memory leaks, but RAII requires a slight mindset-shift in how you write your code. You need to learn to think about declaring your variables in the reverse order of how you want them to be destroyed.

[lowflyer]

So, C++ is scorned, rust is not understood, therefore we just use a private extension of the language. Great!

</sarcasm>

[stompcrash]

Yes. It's a prerequisite to using the Resource Acquisition Is Initialization pattern.

What? How is this a prerequisite to RAII when RAII has existed for decades as a programming paradigm before this _cleanup() compiler feature?

Also, this is about releasing resources, not Acquisition.

I'm guessing that what we have here is the Linux kernel exposing a compiler feature to provide to C programs what in C++ is a destructor. Is that right?

Edit:
Oh, I see in your other comment you do mention destructors. Yea, this functionality already exists since I think the beginning of C++ (so no need for C++26+++ features). And C++ should handle all cases where a variable goes out of scope, not just goto, but (egad) exceptions as well.

[coder]

What? How is this a prerequisite to RAII when RAII has existed for decades as a programming paradigm before this _cleanup() compiler feature?

RAII depends on destructors. It uses an object to bind a resource to a lexical scope. You can't do that without destructors or some equivalent. GCC's cleanup attribute is such an equivalent (for function scope) and it's not new, either. What's new is the kernel's use of it.

Also, this is about releasing resources, not Acquisition.

I'm just telling you what the name stands for. If you don't like the name, don't shoot the messenger. You can read more about it here:

• https://stackoverflow.com/questions/...alization-raii
• https://en.wikipedia.org/wiki/Resour...initialization
• https://learn.microsoft.com/en-us/cp...?view=msvc-170
• https://en.cppreference.com/w/cpp/language/raii

...or like a million other places on the internet.

I'm guessing that what we have here is the Linux kernel exposing a compiler feature to provide to C programs what in C++ is a destructor. Is that right?

Without quibbling too much about wording, yes. And within limits (i.e. local variables only).

C++ should handle all cases where a variable goes out of scope, not just goto, but (egad) exceptions as well.

According to the GCC docs, its cleanup attribute also works during exception-triggered stack unwinds (assuming you compile with support for unwinding).