Aside from being legacy, the old strand class has a significant weakness in the potential to deadlock when multiple connections share the same strand and lock the same objects. This is what happened in #10406, which we fixed by removing the locking in #10857. But with our current ObjectLock-heavy architecture we can't sure that we accidentally introduce another issue like that in the future, because it's hard to test for this kind of strand.impl_ collisions in small non-production setups.
From what I understand, boost::asio::strand<boost::asio::io_context> doesn't share the same implementation objects with other instances and therefore can't be blocked by other connections unless all IO-threads are exhausted.
Compatiblity
boost::asio::strand<boost::asio::io_context> should be supported already in 1.66, but we should do some thorough testing to make sure it's bug free across the whole range of boost-versions we support.
Aside from being legacy, the old strand class has a significant weakness in the potential to deadlock when multiple connections share the same strand and lock the same objects. This is what happened in #10406, which we fixed by removing the locking in #10857. But with our current
ObjectLock-heavy architecture we can't sure that we accidentally introduce another issue like that in the future, because it's hard to test for this kind ofstrand.impl_collisions in small non-production setups.From what I understand,
boost::asio::strand<boost::asio::io_context>doesn't share the same implementation objects with other instances and therefore can't be blocked by other connections unless all IO-threads are exhausted.Compatiblity
boost::asio::strand<boost::asio::io_context>should be supported already in 1.66, but we should do some thorough testing to make sure it's bug free across the whole range of boost-versions we support.