These -fno-exception thing is per-file setting, or can be made a per-target cmake setting.

If one target, rocksdb must compile with -fexceptions, there is no reason for anything else to compile with it.
Or connect, I think it is also using exceptions. Or this single file in tpool, which only catches exception, and does not throw. None of these is a reason to have global flags.

Otherwise, I personally would like to have measurements for how much a noexcept is going to bring us. I'm not getting impressed very much by someone else's unverified results.

Usually, the whole matter of such discussions does not cost a 0.01% or TPS on benchmarks. 

Best,
Wlad
From: Michael Widenius <michael.widenius@gmail.com>
Sent: Monday, April 14, 2025 6:52 PM
To: Marko Mäkelä <marko.makela@mariadb.com>; Vladislav Vaintroub <wlad@mariadb.com>
Cc: commits@lists.mariadb.org <commits@lists.mariadb.org>
Subject: Re: Review of MDL scalability regression after backup locks
 
Hi!

On Mon, Apr 14, 2025 at 9:51 AM Marko Mäkelä <marko.makela@mariadb.com> wrote:
>
> Hi Monty,
>
> Thank you for the review. I will revise
> https://github.com/MariaDB/server/pull/3966/ accordingly.
>
> When it comes to the C++11 noexcept keyword, I believe that there was
> a reason why -fno-exceptions was included in all the applicable build
> scripts in the very first public revision of MySQL
...

Note that I am not against adding noexcept keyword to functions.
I just not want to do this in one only place and as part of working on something
completely different.
We should consider adding noexcept to functions in a separate commit
or alternately
go back to using --fno-exceptions and fix wsrep-lib and
tpool_generic.cc to not use exceptions.
The only other software that we have that is using exceptions is
rocksdb.  For builds with rocksdb we could enable exceptions.

I think it would be preferably to fix the few cases we have that uses
exceptions instead of having to add noexpect to EVERY other functions
in MariaDB.

Regards,
Monty