Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: mark functions noexcept in C++ #1117

Open
rohanlean opened this issue Apr 4, 2024 · 2 comments
Open

Feature request: mark functions noexcept in C++ #1117

rohanlean opened this issue Apr 4, 2024 · 2 comments

Comments

@rohanlean
Copy link

Hi,

first of all, many thanks for creating io_uring!

Because you seem to be using raw syscalls everywhere instead of POSIX wrappers that could be cancellation points, the functions in liburing thankfully do not throw and probably never will. Yet they are not marked noexcept, which inhibits optimisations.

I propose that all functions be marked noexcept.

@isilence
Copy link
Collaborator

Apparently, extern "C" doesn't imply noexcept and it might be worth to add.
I wonder though, have you tried it? Any what's the difference in binary size / assembly?

@rohanlean
Copy link
Author

Yes, it absolutely makes a difference. A missing noexcept can prevent code motion, dead-code elimination, and a cascade of other optimisation. For a simple example consider T x; for (;;) io_uring_enter(...). Unless the compiler knows that io_uring_enter does not throw, it needs to insert a call to (and possibly generate) the destructor of T, possibly insert a call to (and link) std::terminate, generate unwind tables, etc.

It is worth also marking the the functions with __attribute__(nothrow) in C (if supported), by the way. Some C code is compiled with exceptions enabled, and it can make a difference there. For example Fedora compiles everything with exceptions enabled. You can look at how glibc defines its __THROW macro in sys/cdefs.h.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants