Monty and I had an argument recently regarding pthread_yield() and std::this_thread::yield() usage. I do want to make this discussion public, so that we can pick either approach, get it documented and make sure everybody is aware of reasoning and decision. Probably even add a bb check that wouldn't allow unwanted function calls to pass. Lets try to keep this discussion focused on std::this_thread::yield() and avoid discussing other C++11 features. Since I'm biased towards std::this_thread::yield() I'd let Monty elaborate his concerns and explain why he prefers pthread_yield(). But generally it comes to compatibility and portability. My position is: pthread_yield() should be removed in favour of std::this_thread::yield(). Benefits: 1. Must be available to all current MariaDB versions. C++11 is a must since 2018. 2. Compatibility and portability, which we don't have to care about. 3. I have no performance concerns after analysing how it is implemented by clang and gcc. 4. Goes inline with "MDEV-35461 - Remove redundant checks for standard library functions" 5. Standard things looks more community-friendly, e.g. why should MSVC developers care about POSIX threads? Currently pthread_yield() can be defined to: 1. SwitchToThread() - Win32 (Wlad, 2009) MSVC seems to support std::this_thread::yield() since 2015: https://learn.microsoft.com/en-us/cpp/standard-library/thread-functions?view... 2. thr_yield() - Solaris (Serg, 2009) Oracle Developer Studio 12.6 supports std::this_thread::yield() since 2017: https://docs.oracle.com/cd/E77782_01/html/E77789/bkabe.html#OSSCPgnyio 3. pthread_yield_np() - OS X (Serg, 2009) XCode is based on clang, which supports std::this_thread::yield() since 2013. sched_yield() - default (Serg, 2009) pthread_yield() - deprecated since 2021 (Serg, 2009) Possible concerns: 1. Compatibility with recent platforms. C++11 is widely available, thread models seem to be well supported. InnoDB uses std::this_thread_yield() since 2021. 2. Compatibility with older (ancient?) platforms. We're way off into C++11 since 2018. Making recent MariaDB compile on such platforms is probably going to be a heavy effort. If we do really want to have these platforms supported, they must be present in buildbot. 3. Performance impact of std::this_thread::yield(). See below. In many cases it is just a wrapper around functions like sched_yield. clang: libcxx/include/__thread/this_thread.h:inline _LIBCPP_HIDE_FROM_ABI void yield() _NOEXCEPT { __libcpp_thread_yield(); } libcxx/src/support/win32/thread_win32.cpp:void __libcpp_thread_yield() { SwitchToThread(); } libcxx/include/__thread/support/pthread.h:inline _LIBCPP_HIDE_FROM_ABI void __libcpp_thread_yield() { sched_yield(); } gcc additionally supports VxWorks: yield() noexcept { #if defined _GLIBCXX_HAS_GTHREADS && defined _GLIBCXX_USE_SCHED_YIELD __gthread_yield(); #endif } int __gthread_yield (void) { return taskDelay (0); } __GTHREAD_INLINE int __gthread_yield (void) { return __gthrw_(sched_yield) (); } Regards, Sergey
On Fri, 9 May 2025 at 07:54, Sergey Vojtovich via developers < developers@lists.mariadb.org> wrote:
Monty and I had an argument recently regarding pthread_yield() and std::this_thread::yield() usage.
My position is: pthread_yield() should be removed in favour of std::this_thread::yield(). Benefits:
Agree here.
1. Must be available to all current MariaDB versions. C++11 is a must since 2018.
per https://jira.mariadb.org/browse/MDEV-35837 we've declared our current standard on 11.8+ as C++17
2. Compatibility and portability, which we don't have to care about.
I do pity our FreeBSD/OpenBSD/Illumios/MacOS maintainers that frequently submit one or two changes every second release.
3. I have no performance concerns after analysing how it is implemented by clang and gcc. 4. Goes inline with "MDEV-35461 - Remove redundant checks for standard library functions" 5. Standard things looks more community-friendly, e.g. why should MSVC developers care about POSIX threads?
To attract new developers, both employment and contributions, we should use all stable features that exist in the compilers supported by the supported distros of our codebase. It seems the mariadb.com job adverts on Senior C++ Database Engine Developer have qualification "You use the C++20 standard since 2020 and C++17 since 2017.". How disappointed are they going to be in employment when C++20 is a no go and even C++17 construct usage is rare? Do you think staff will be retained up until when C++20 becomes allowed is to be possible? Insisting on code constructs that existed before many new developers are born is a sure way to put them off. Thinking back to my early career (also a a long time ago) I had no desire to work on COBOL or Fortran (even though I didn't and still don't know anything about them). To avoid a "I worked on those", this isn't a reflection of the technology, just I didn't, and still aren't, in tech to work on "old stuff". The Foundation goal of continuity and openness can only be met while people are willing and able to work in the codebase. 6. complexity Currently highlighted below, the variety of options is creating large complexity in the codebase. We should trust, but validate via testing that C++ implementers can implement these appropriately. They have great skills, and are typically employed by a distro or hardware platform company that has easy access to those hardware professionals to validate an exceptionally optimal implementation. As a highlight of an old PR of mine where we took a "we know better stance" and never re-revaluted in 18 years https://github.com/MariaDB/server/pull/698 (which got effect, but we retained the old code under a not accessible define, but still got effort better spent elsewhere put into it recently maintain to conform to compatible behaviour). As our current bug queue indicates that we've got enough to handle on the database layer of things without maintaining, dare I exaggerate slightly not-invented-here, low level constructs well maintained elsewhere.
Currently pthread_yield() can be defined to:
1. SwitchToThread() - Win32 (Wlad, 2009)
...
Hi, Daniel, On May 09, Daniel Black via developers wrote:
It seems the mariadb.com job adverts on Senior C++ Database Engine Developer have qualification "You use the C++20 standard since 2020 and C++17 since 2017.".
This is a ColumnStore position, ColumnStore is much more bleeding edge. Regards, Sergei Chief Architect, MariaDB Server and security@mariadb.org
One concern could be that dropping our sched_yield wrappers, or worsening its maintenance would affect the C part of the server, but I just checked that there is a C11 function as well: https://en.cppreference.com/w/c/thread/thrd_yield I remember, though, that some systems don't supply threads.h, or supply a picky set out of it. C++ is much more defined on what it provides. I think, C++-wide, we could stick to std::this_thread::yield. Modern toolset looks more attractive for a wide range of developers. There is still C, where pthread_yield would still be the way. Though, is doesn't address the "why windows developers should care about pthread" concern. So, for C, i'd suggest to transform my_pthread.h into C11 compatibility layer provider: 1. create a threads.h file 2. if HAS_THREADS_H is defined, it should #include_next it. 3. rename pthread_yield macro into thrd_yield and move it to our threads.h 4. include threads.h in my_pthread.h 5. our threads.h may be expanded with other stuff Alternatively, we can just use thrd_yield name everywhere, which is another new standard way in the C world! Though i guess much less known, than std::this_thread::yield. Regards, Nikita On Fri, 9 May 2025 at 08:43, Sergei Golubchik via developers < developers@lists.mariadb.org> wrote:
Hi, Daniel,
On May 09, Daniel Black via developers wrote:
It seems the mariadb.com job adverts on Senior C++ Database Engine Developer have qualification "You use the C++20 standard since 2020 and C++17 since 2017.".
This is a ColumnStore position, ColumnStore is much more bleeding edge.
Regards, Sergei Chief Architect, MariaDB Server and security@mariadb.org _______________________________________________ developers mailing list -- developers@lists.mariadb.org To unsubscribe send an email to developers-leave@lists.mariadb.org
-- Yours truly, Nikita Malyavin
Just want to add, that I think it's fine to have two different interfaces for communicating with OS: one for C and another one for C++, just as we use new(mem_root) in C++ and we have alloc_root for C. Same for atomics. And if we'll have to support more (older) platforms, the library stuff is easily coverable with similar compatibility layers for C++.
Hi Nikita, Back, when I was writing the original e-mail I didn't realize that we're still on C99. Yes, we'll definitely have to have different interfaces. I wonder if we're considering moving towards C11. Then we could probably try disabling our pthread_yield() and see if thrd_yield() is available on all supported platforms. Offtop: I really can't wait when we can finish our ugly atomics. Both us and MySQL team have wasted enormous resources maintaining it. Not talking about users suffering from bugs. Below is atomics pain that I alone had to experience. It is most probably an incomplete list of my commits. Hope it explains my left eye twitching when I see non-standard stuff when standard replacement is available. c0ebb3f38811c6a0e3e2b49b3ae40b4ea0c2b0e9 6192f0bffa798c01acc85db9f427ed02234aead4 53360fd45f89e9b16aac69625820988702a339ee 82ce2a2503a95e8bdc76c351a87e98c93445a433 40497577ffd9f85557b15e08ad913f627b2e9530 c01c819209fdf09b4ba95f34d87d0617776f47cd 4472a0ef95ba3257125f5aee0b2b953acc43364d ed313e8a92a836422b9ae7b9ecf11c44ed4d5d66 e13459a11eb5938b54b88c7a1529491df6dd3b49 6bd76f8b7e086ab7cf0249a05277ff552e564554 edf6354bd6389ce1ca79591fe79deef4df6eca95 f31a89191f6b1679d9f8b584aa95fe006182ee7d 3d1a7cba71f6c843639f0b9a48b12017ff610112 d055e28f61ef44f2fdbd139edcaf191c96d14e68 f4d885c4e9d929639b7075b7382b439f0b4e3cc1 5608a737ea7b5630452957b82deff4c76406041e 2b47f8ff03845f7ffe2fa3bd583dd4123dae2b61 8303aded294ce905bbc513e7ee42623d5f1fdb50 bb7e84b79ab5243392e3691c27d6d64566e26b39 8d010c44ef6f156566bcd5ff7fbdcf23ef96e92e 68a853732750902fbd97e8ddd1a7f264f9b199c9 fb7caad72b5c37e96c69aad63f9589f8b56855d6 1a1749e38c774ce3a3493da2410b19ebe71eccb5 c73e77da0fa0fbdb4be5bfa1f4e441b06d1d91f9 57d20f1132df71e3b9aca998bcc31dfd62c942b3 5b624f00fc0e6fa0a5a676d3ec445f62c0fb75ec 51bb18f989d198aa648b2481865abd0734520d35 b04f2a0f01902d11e21afb690e14d12d2c464184 03e461634d725a66917f8161443710f4338a5b1e 90377b8028e0103f967d81fd0cbb8ede99d8215a 8023fc6d453aebb2554289d4ed2ab595093a0f14 4abdd798f75e345f8692118634c464073de2cda5 67dbfe6e9ced31ce1e4bb2c60ffbb25c2055c6ec 5c657e9fa55787de4cb10c81a7a0459be48844d4 2e5d35961d87e073a9809bbc03813f45d246cbec 601f45fdcd72ddd357ad12f39786a7c74423fdde 6a150e26d94a75b0b72acc418c2532592fd769e5 e976c7dbf20a997c5ba4e9e780848a01b392dd24 dab38ce0232f248843e9a53671ab4fa1d0620e72 4404ee29010efe02292373411991e4433a9e57bd 9581c4a8f5d6c87a6d34c6d3b826c32bf7f15143 e60dc209d492e237234dac63293e33558a0daba7 8c82ca171e562a9d55c5c59a02ead2567212c67b d93653bf968ebdaecaace449808577100821cc8d b1c3e6c2f27b9da5a4a6bc75f1cf6a4b1d7e3127 de32e66336a387bb0391a9861b927799ed007a97 edde1f6e0d5f5a0115a5253c9b8d428af132f2d1 66ec8adb77856d5fa6b77edf3ee8471576c30938 dbd40edfe680ebaea529b97c3dafa20cb1f40f4e 4ef481f5bce5f1ed6c21fc03a65a2d844e5729f8 5cc6b48f39c7c8ec9c5a56d6ac6e639bd660480f f401ba477ce66b66b8db5a52eb39e0d7d7b97eb3 0ce7f6b0bf68df34adcd22b864f0ddb37218297c 830a7c67a4eefa1091bad4b60617309b9f299c96 dc90234bda3e2074179a3e54c09a7c9694e69965 adc30ecab52c661689b18045a69b607ee6d42495 28d627392b3ea39ceefd8df7451813da660bf19d fbe2a5b7d691f9742053623517e7fd8639562e63 54b3fd25813117ab8eaa6c22a963ee16c0dec224 656a702ca9318c58fde97e19ba7b242d11c05c56 c6a00544ff948dc3eafba0e7f0db39ddb352a3b1 66bca0dfa9909ff4078a9973d35c2c80e1927d07 e2d96e8a16704c02248c9039028f9de17c887846 9e37537c4e9c8b5cc5aff75b6e891be4cd877573 c66db377d75b40c42f336223ac865e4820698e55 39a8caa51c115e7750c2355374413056932665eb 65083ba64c4d77b5821816bda1bbed77f6c7961a e9a5f288f21c15ec6b4d2dd3d654a320904bb1bf 81f700015e746ac590b55bcb21bf21ba0d6febfc 5679a2b6b342abc9d80bcf784a1a35f240be9d87 9836fd5d131e405106508a5f706268e371418e05 e813f9b9b3a087910b94ffeda968b53f9fca4311 71e11bce34339a69576321d6c40838fa65208dc7 1369e70b561a53dd77da3c0b87217cf2d6c8328d 8f9999b5fc658431cac66cf07b51b3f469faa20a bb9928160fce03c64bbf753e7eafbdbd95255110 8ff3b892aeac2e320d701652539476c4d9e7b591 c23399d3de8275c75b833e6fb64ed4efc433fb7a 81f280789b30c070ce6e854dddcd59b28b81af7a c10e523d78756348d7128aff4bc00dcef8a0bec9 77a5dab5a279572b680383d6d6c0a09e404fffd9 1029b22feb8d9768df9e8b7b0344e2961bf82659 c60095a818dce92838940525899a13a05633d148 Regards, Sergey On Fri, May 16, 2025 at 10:28 PM Nikita Malyavin via developers < developers@lists.mariadb.org> wrote:
Just want to add, that I think it's fine to have two different interfaces for communicating with OS: one for C and another one for C++, just as we use new(mem_root) in C++ and we have alloc_root for C. Same for atomics.
And if we'll have to support more (older) platforms, the library stuff is easily coverable with similar compatibility layers for C++. _______________________________________________ developers mailing list -- developers@lists.mariadb.org To unsubscribe send an email to developers-leave@lists.mariadb.org
Sergey, I've enabled c11 for parsec plugin at first. Then it ran in a pile of problems with threads.h availability an ended up in removing c11 support. https://github.com/mariadb-corporation/mariadb-connector-c/commit/b827743c27... Still, even with c99 we can have our own threads.h providing (C11-)standard-compatible names! Btw, I recall some progress on "replacing the ugly atomics", namely: https://github.com/MariaDB/server/pull/2961 Regards, Nikita On Fri, 16 May 2025 at 21:31, Sergey Vojtovich <svojtovich@gmail.com> wrote:
Hi Nikita,
Back, when I was writing the original e-mail I didn't realize that we're still on C99. Yes, we'll definitely have to have different interfaces. I wonder if we're considering moving towards C11. Then we could probably try disabling our pthread_yield() and see if thrd_yield() is available on all supported platforms.
Offtop: I really can't wait when we can finish our ugly atomics. Both us and MySQL team have wasted enormous resources maintaining it. Not talking about users suffering from bugs.
Below is atomics pain that I alone had to experience. It is most probably an incomplete list of my commits. Hope it explains my left eye twitching when I see non-standard stuff when standard replacement is available.
c0ebb3f38811c6a0e3e2b49b3ae40b4ea0c2b0e9 6192f0bffa798c01acc85db9f427ed02234aead4 53360fd45f89e9b16aac69625820988702a339ee 82ce2a2503a95e8bdc76c351a87e98c93445a433 40497577ffd9f85557b15e08ad913f627b2e9530 c01c819209fdf09b4ba95f34d87d0617776f47cd 4472a0ef95ba3257125f5aee0b2b953acc43364d ed313e8a92a836422b9ae7b9ecf11c44ed4d5d66 e13459a11eb5938b54b88c7a1529491df6dd3b49 6bd76f8b7e086ab7cf0249a05277ff552e564554 edf6354bd6389ce1ca79591fe79deef4df6eca95 f31a89191f6b1679d9f8b584aa95fe006182ee7d 3d1a7cba71f6c843639f0b9a48b12017ff610112 d055e28f61ef44f2fdbd139edcaf191c96d14e68 f4d885c4e9d929639b7075b7382b439f0b4e3cc1 5608a737ea7b5630452957b82deff4c76406041e 2b47f8ff03845f7ffe2fa3bd583dd4123dae2b61 8303aded294ce905bbc513e7ee42623d5f1fdb50 bb7e84b79ab5243392e3691c27d6d64566e26b39 8d010c44ef6f156566bcd5ff7fbdcf23ef96e92e 68a853732750902fbd97e8ddd1a7f264f9b199c9 fb7caad72b5c37e96c69aad63f9589f8b56855d6 1a1749e38c774ce3a3493da2410b19ebe71eccb5 c73e77da0fa0fbdb4be5bfa1f4e441b06d1d91f9 57d20f1132df71e3b9aca998bcc31dfd62c942b3 5b624f00fc0e6fa0a5a676d3ec445f62c0fb75ec 51bb18f989d198aa648b2481865abd0734520d35 b04f2a0f01902d11e21afb690e14d12d2c464184 03e461634d725a66917f8161443710f4338a5b1e 90377b8028e0103f967d81fd0cbb8ede99d8215a 8023fc6d453aebb2554289d4ed2ab595093a0f14 4abdd798f75e345f8692118634c464073de2cda5 67dbfe6e9ced31ce1e4bb2c60ffbb25c2055c6ec 5c657e9fa55787de4cb10c81a7a0459be48844d4 2e5d35961d87e073a9809bbc03813f45d246cbec 601f45fdcd72ddd357ad12f39786a7c74423fdde 6a150e26d94a75b0b72acc418c2532592fd769e5 e976c7dbf20a997c5ba4e9e780848a01b392dd24 dab38ce0232f248843e9a53671ab4fa1d0620e72 4404ee29010efe02292373411991e4433a9e57bd 9581c4a8f5d6c87a6d34c6d3b826c32bf7f15143 e60dc209d492e237234dac63293e33558a0daba7 8c82ca171e562a9d55c5c59a02ead2567212c67b d93653bf968ebdaecaace449808577100821cc8d b1c3e6c2f27b9da5a4a6bc75f1cf6a4b1d7e3127 de32e66336a387bb0391a9861b927799ed007a97 edde1f6e0d5f5a0115a5253c9b8d428af132f2d1 66ec8adb77856d5fa6b77edf3ee8471576c30938 dbd40edfe680ebaea529b97c3dafa20cb1f40f4e 4ef481f5bce5f1ed6c21fc03a65a2d844e5729f8 5cc6b48f39c7c8ec9c5a56d6ac6e639bd660480f f401ba477ce66b66b8db5a52eb39e0d7d7b97eb3 0ce7f6b0bf68df34adcd22b864f0ddb37218297c 830a7c67a4eefa1091bad4b60617309b9f299c96 dc90234bda3e2074179a3e54c09a7c9694e69965 adc30ecab52c661689b18045a69b607ee6d42495 28d627392b3ea39ceefd8df7451813da660bf19d fbe2a5b7d691f9742053623517e7fd8639562e63 54b3fd25813117ab8eaa6c22a963ee16c0dec224 656a702ca9318c58fde97e19ba7b242d11c05c56 c6a00544ff948dc3eafba0e7f0db39ddb352a3b1 66bca0dfa9909ff4078a9973d35c2c80e1927d07 e2d96e8a16704c02248c9039028f9de17c887846 9e37537c4e9c8b5cc5aff75b6e891be4cd877573 c66db377d75b40c42f336223ac865e4820698e55 39a8caa51c115e7750c2355374413056932665eb 65083ba64c4d77b5821816bda1bbed77f6c7961a e9a5f288f21c15ec6b4d2dd3d654a320904bb1bf 81f700015e746ac590b55bcb21bf21ba0d6febfc 5679a2b6b342abc9d80bcf784a1a35f240be9d87 9836fd5d131e405106508a5f706268e371418e05 e813f9b9b3a087910b94ffeda968b53f9fca4311 71e11bce34339a69576321d6c40838fa65208dc7 1369e70b561a53dd77da3c0b87217cf2d6c8328d 8f9999b5fc658431cac66cf07b51b3f469faa20a bb9928160fce03c64bbf753e7eafbdbd95255110 8ff3b892aeac2e320d701652539476c4d9e7b591 c23399d3de8275c75b833e6fb64ed4efc433fb7a 81f280789b30c070ce6e854dddcd59b28b81af7a c10e523d78756348d7128aff4bc00dcef8a0bec9 77a5dab5a279572b680383d6d6c0a09e404fffd9 1029b22feb8d9768df9e8b7b0344e2961bf82659 c60095a818dce92838940525899a13a05633d148
Regards, Sergey
On Fri, May 16, 2025 at 10:28 PM Nikita Malyavin via developers < developers@lists.mariadb.org> wrote:
Just want to add, that I think it's fine to have two different interfaces for communicating with OS: one for C and another one for C++, just as we use new(mem_root) in C++ and we have alloc_root for C. Same for atomics.
And if we'll have to support more (older) platforms, the library stuff is easily coverable with similar compatibility layers for C++. _______________________________________________ developers mailing list -- developers@lists.mariadb.org To unsubscribe send an email to developers-leave@lists.mariadb.org
-- Yours truly, Nikita Malyavin
I do not think we have to absolutely support C11. We require C++ compiler that is on C++11 standard. If we need to interact with external C code for some reasons,. we can, via extern "C". from within C++.file, for exported functions- As for .c files currently in the codebase, I see no reason why they need to stay .c forever, and no reason why they can't be renamed to .cc, if they require this "yield" . It is not an insurmountable problem. If anything, this will add some good warnings and some type safety On Fri, May 16, 2025 at 10:21 PM Nikita Malyavin via developers < developers@lists.mariadb.org> wrote:
Sergey,
I've enabled c11 for parsec plugin at first. Then it ran in a pile of problems with threads.h availability an ended up in removing c11 support.
https://github.com/mariadb-corporation/mariadb-connector-c/commit/b827743c27...
Still, even with c99 we can have our own threads.h providing (C11-)standard-compatible names!
Btw, I recall some progress on "replacing the ugly atomics", namely: https://github.com/MariaDB/server/pull/2961
Regards, Nikita
On Fri, 16 May 2025 at 21:31, Sergey Vojtovich <svojtovich@gmail.com> wrote:
Hi Nikita,
Back, when I was writing the original e-mail I didn't realize that we're still on C99. Yes, we'll definitely have to have different interfaces. I wonder if we're considering moving towards C11. Then we could probably try disabling our pthread_yield() and see if thrd_yield() is available on all supported platforms.
Offtop: I really can't wait when we can finish our ugly atomics. Both us and MySQL team have wasted enormous resources maintaining it. Not talking about users suffering from bugs.
Below is atomics pain that I alone had to experience. It is most probably an incomplete list of my commits. Hope it explains my left eye twitching when I see non-standard stuff when standard replacement is available.
c0ebb3f38811c6a0e3e2b49b3ae40b4ea0c2b0e9 6192f0bffa798c01acc85db9f427ed02234aead4 53360fd45f89e9b16aac69625820988702a339ee 82ce2a2503a95e8bdc76c351a87e98c93445a433 40497577ffd9f85557b15e08ad913f627b2e9530 c01c819209fdf09b4ba95f34d87d0617776f47cd 4472a0ef95ba3257125f5aee0b2b953acc43364d ed313e8a92a836422b9ae7b9ecf11c44ed4d5d66 e13459a11eb5938b54b88c7a1529491df6dd3b49 6bd76f8b7e086ab7cf0249a05277ff552e564554 edf6354bd6389ce1ca79591fe79deef4df6eca95 f31a89191f6b1679d9f8b584aa95fe006182ee7d 3d1a7cba71f6c843639f0b9a48b12017ff610112 d055e28f61ef44f2fdbd139edcaf191c96d14e68 f4d885c4e9d929639b7075b7382b439f0b4e3cc1 5608a737ea7b5630452957b82deff4c76406041e 2b47f8ff03845f7ffe2fa3bd583dd4123dae2b61 8303aded294ce905bbc513e7ee42623d5f1fdb50 bb7e84b79ab5243392e3691c27d6d64566e26b39 8d010c44ef6f156566bcd5ff7fbdcf23ef96e92e 68a853732750902fbd97e8ddd1a7f264f9b199c9 fb7caad72b5c37e96c69aad63f9589f8b56855d6 1a1749e38c774ce3a3493da2410b19ebe71eccb5 c73e77da0fa0fbdb4be5bfa1f4e441b06d1d91f9 57d20f1132df71e3b9aca998bcc31dfd62c942b3 5b624f00fc0e6fa0a5a676d3ec445f62c0fb75ec 51bb18f989d198aa648b2481865abd0734520d35 b04f2a0f01902d11e21afb690e14d12d2c464184 03e461634d725a66917f8161443710f4338a5b1e 90377b8028e0103f967d81fd0cbb8ede99d8215a 8023fc6d453aebb2554289d4ed2ab595093a0f14 4abdd798f75e345f8692118634c464073de2cda5 67dbfe6e9ced31ce1e4bb2c60ffbb25c2055c6ec 5c657e9fa55787de4cb10c81a7a0459be48844d4 2e5d35961d87e073a9809bbc03813f45d246cbec 601f45fdcd72ddd357ad12f39786a7c74423fdde 6a150e26d94a75b0b72acc418c2532592fd769e5 e976c7dbf20a997c5ba4e9e780848a01b392dd24 dab38ce0232f248843e9a53671ab4fa1d0620e72 4404ee29010efe02292373411991e4433a9e57bd 9581c4a8f5d6c87a6d34c6d3b826c32bf7f15143 e60dc209d492e237234dac63293e33558a0daba7 8c82ca171e562a9d55c5c59a02ead2567212c67b d93653bf968ebdaecaace449808577100821cc8d b1c3e6c2f27b9da5a4a6bc75f1cf6a4b1d7e3127 de32e66336a387bb0391a9861b927799ed007a97 edde1f6e0d5f5a0115a5253c9b8d428af132f2d1 66ec8adb77856d5fa6b77edf3ee8471576c30938 dbd40edfe680ebaea529b97c3dafa20cb1f40f4e 4ef481f5bce5f1ed6c21fc03a65a2d844e5729f8 5cc6b48f39c7c8ec9c5a56d6ac6e639bd660480f f401ba477ce66b66b8db5a52eb39e0d7d7b97eb3 0ce7f6b0bf68df34adcd22b864f0ddb37218297c 830a7c67a4eefa1091bad4b60617309b9f299c96 dc90234bda3e2074179a3e54c09a7c9694e69965 adc30ecab52c661689b18045a69b607ee6d42495 28d627392b3ea39ceefd8df7451813da660bf19d fbe2a5b7d691f9742053623517e7fd8639562e63 54b3fd25813117ab8eaa6c22a963ee16c0dec224 656a702ca9318c58fde97e19ba7b242d11c05c56 c6a00544ff948dc3eafba0e7f0db39ddb352a3b1 66bca0dfa9909ff4078a9973d35c2c80e1927d07 e2d96e8a16704c02248c9039028f9de17c887846 9e37537c4e9c8b5cc5aff75b6e891be4cd877573 c66db377d75b40c42f336223ac865e4820698e55 39a8caa51c115e7750c2355374413056932665eb 65083ba64c4d77b5821816bda1bbed77f6c7961a e9a5f288f21c15ec6b4d2dd3d654a320904bb1bf 81f700015e746ac590b55bcb21bf21ba0d6febfc 5679a2b6b342abc9d80bcf784a1a35f240be9d87 9836fd5d131e405106508a5f706268e371418e05 e813f9b9b3a087910b94ffeda968b53f9fca4311 71e11bce34339a69576321d6c40838fa65208dc7 1369e70b561a53dd77da3c0b87217cf2d6c8328d 8f9999b5fc658431cac66cf07b51b3f469faa20a bb9928160fce03c64bbf753e7eafbdbd95255110 8ff3b892aeac2e320d701652539476c4d9e7b591 c23399d3de8275c75b833e6fb64ed4efc433fb7a 81f280789b30c070ce6e854dddcd59b28b81af7a c10e523d78756348d7128aff4bc00dcef8a0bec9 77a5dab5a279572b680383d6d6c0a09e404fffd9 1029b22feb8d9768df9e8b7b0344e2961bf82659 c60095a818dce92838940525899a13a05633d148
Regards, Sergey
On Fri, May 16, 2025 at 10:28 PM Nikita Malyavin via developers < developers@lists.mariadb.org> wrote:
Just want to add, that I think it's fine to have two different interfaces for communicating with OS: one for C and another one for C++, just as we use new(mem_root) in C++ and we have alloc_root for C. Same for atomics.
And if we'll have to support more (older) platforms, the library stuff is easily coverable with similar compatibility layers for C++. _______________________________________________ developers mailing list -- developers@lists.mariadb.org To unsubscribe send an email to developers-leave@lists.mariadb.org
-- Yours truly, Nikita Malyavin _______________________________________________ developers mailing list -- developers@lists.mariadb.org To unsubscribe send an email to developers-leave@lists.mariadb.org
participants (5)
-
Daniel Black -
Nikita Malyavin -
Sergei Golubchik -
Sergey Vojtovich -
Vladislav Vaintroub