Remove boost_sync #4918
Remove boost_sync #4918
Conversation
|
whoops, please wait to review, this has legitimate linting issues :) sorry |
mostly requires just changing the include and type. in one case (PyrSched.cpp) requires using a new API. confirmed locally that this works as expected. remove references to boost_sync in cmake and extract_boost add interprocess semaphore files update extract_boost migrate to boost.ip.semaphore
mossheim
force-pushed
the
topic/remove-boost-sync
branch
from
b88f45a
to
2b21115
Compare
|
@brianlheim don't! semaphores in boost.interprocess and semaphores in boost.sync are two different beasts: interprocess semaphores are, well, interprocess and much slower that what is in boost.sync. if boost.sync doesn't build with 1.73, that has to be fixed (please file a bug report for boost.sync) especially for supernova the semaphore performance is critical |
|
oh, i see! would the std::binary_semaphore from c++20 be a suitable replacement in your opinion @timblechmann ? thanks for the warning, and sorry for my negligence here. apologies are also due to @dyfer then for my arrogance in assuming this was so cut-and-dry when we talked about it earlier. i do think boost.sync -- at least, the latest version -- will build with 1.73; but, i'm not sure it will build with 1.66 that we package in 3.11, and i didn't bother to find out since it seemed easier to do this port. i'll do some more research. |
|
thanks @brianlheim and no worries! I'm glad someone with more expertise than me chimed in on the issue. |
|
i hope that the c++20 semaphores (binary or counting) will have a good implementation, so they will probably be the way to go once they are widely available (macos for example has 3 different semaphore implementations, i hope the libc++ implementation will use dispatch semaphores rather than system v). in general i'd rather recommend updating boost and boost.sync to solve those build issues. |
|
thanks! yes definitely, now that i know the boost.sync semaphores aren't available anywhere else i'll keep them around. i was happy to find that boost.sync is still being actively maintained |
Purpose and Motivation
Fixes #4914 (confirmed locally using the boost from the source release)
I know this looks like a big change, but see #4914 for my reasoning. This is actually quite safe in terms of the amount of code that had to be ported.
There was only one place where i had to make a substantial change, in PyrSched.cpp, and i confirmed locally with a test program that this works as expected.
Types of changes
To-do list