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