From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2021-12-01 12:10:39
On 12/1/21 00:40, Oliver Kowalke via Boost wrote:
> Andrey Semashev via Boost <boost_at_[hidden]> schrieb am Di., 30. Nov.
> 2021, 21:00:
>> On 11/30/21 22:28, Peter Dimov via Boost wrote:
>>> Andrzej Krzemienski wrote:
>>>> Please correct me if I am wrong, but my understanding is that Boost.ASIO
>>>> works under C++03, and so does Boost.Coroutine. Whereas Boost.Coroutine2
>>>> requires C++11. If Boost.ASIO were to switch from BoostCoroutine to
>>>> Boost.Coroutine2, it would break its C++03 guarantee. (Some teams in my
>>>> work still have to use C++03.)
>>> It's a bit more complex than that. Boost.Coroutine depends on
>>> which is C++11. However, in order to not break C++03, Coroutine doesn't
>>> the public API of Context, but the private "fcontext" parts that are
>> kept C++03
>>> compatible only because of that. This incidentally means that if you
>>> Context with the `ucontext` backend instead of the `fcontext` one,
>>> Coroutine breaks.
>>> So it's basically a mess and needs to be cleaned up. Since asio::spawn
>> is a
>>> separate part of Asio, moving just it to C++11 wouldn't be as disruptive
>>> change as requiring C++11 for all of Asio.
>> I wonder how much of Boost.Context actually requires C++11. From my
>> admittedly naive perspective, it should mostly be a bunch of assembler
>> bits and/or interface glue for system APIs like ucontext, none of which
>> inherently requires C++11
> It's described in the C++ proposal ...
> lifecycle, stack must be managed + ownership and state (for instance
> resuming an already running fiber).
IMHO, fiber execution, and the fiber class itself, should be a separate
library, which may require C++11. It was my understanding that this is
what Boost.Coroutine and Boost.Coroutine2 are for. Boost.Context, on the
other hand, would only contain low level code for saving and restoring
thread context and nothing else. This kind functionality doesn't seem
like dependent on C++11 features.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk