Is there interest in an "iofiber" library?
I have written a completion token for Boost.Asio that is a little more advanced than plain ASIO's spawn featuring abstractions such as join(), detach() and even interrupt(). I'd like to know if there is interest in seeing this library merged as part of Boost. https://vinipsmaker.github.io/iofiber/ (there is also a mutex and a semaphore, but these are undocumented as of now and were poorly ported from the previous token supporting abstractions and need rework) Boost.Fiber integration with ASIO is problematic: https://github.com/boostorg/fiber/issues/102#issuecomment-263558882 Default Boost.Asio yield token will do as long as you don't need communication between fibers. When primitive communication is necessary, you can work around it by exploiting the completion token protocol. In fact, after having rolled my own solution, I eventually was made aware of Peter's solution (which he rolled on his own independently) which was incredibly similar to my solution: https://github.com/equalitie/ouinet/blob/a2afaf9932c8a23434d1f0a10be06fc4077... If you need anything more advanced such as careful strand integration, join, or interruption API, you'll just have to roll your own token. That's what I end up doing after working around ASIO's token for many months. There was also a recent request by Vinnie to turn Boost.Coroutine 1 deprecation warning off. This separate library would be an alternative (although it is still a far from review-ready). -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/
On Wed, Jan 2, 2019, 6:47 AM Vinícius dos Santos Oliveira via Boost < boost@lists.boost.org wrote:
I have written a completion token for Boost.Asio that is a little more advanced than plain ASIO's spawn featuring abstractions such as join(), detach() and even interrupt().
I'd like to know if there is interest in seeing this library merged as part of Boost.
This may be a dumb question, but could ASIO's stackful coroutine completion token be extended to have the functionality you need?
Em sex, 4 de jan de 2019 às 21:16, David Sankel <camior@gmail.com> escreveu:
This may be a dumb question, but could ASIO's stackful coroutine completion token be extended to have
I could change ASIO's stackful coroutine completion token to have the functionality I need (maybe with some small breakage), but I don't want to increase the burden maintenance on Chris' back. That's basically the motivation to avoid sending a PR and starting a new lib. Maybe other problems would be: - The dependency on C++11 (e.g. fiber objects are move-only handles just like thread objects). ASIO is a C++98 library. - Scope-creep within ASIO? the functionality you need?
I'm not the only one who needs this functionality. I'm not the only one avoiding Boost.Fiber because integration with ASIO is problematic. I'm not the only one reinventing thread patterns and cancellation patterns on top of ASIO's completion token. Others are doing it independently. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/
On Sat, Jan 5, 2019 at 2:57 AM Vinícius dos Santos Oliveira < vini.ipsmaker@gmail.com> wrote:
Em sex, 4 de jan de 2019 às 21:16, David Sankel <camior@gmail.com> escreveu:
This may be a dumb question, but could ASIO's stackful coroutine completion token be extended to have
I could change ASIO's stackful coroutine completion token to have the functionality I need (maybe with some small breakage), but I don't want to increase the burden maintenance on Chris' back. That's basically the motivation to avoid sending a PR and starting a new lib.
Maybe other problems would be:
- The dependency on C++11 (e.g. fiber objects are move-only handles just like thread objects). ASIO is a C++98 library. - Scope-creep within ASIO?
It seems like it would be a good idea to broach the subject with Chris to see what his thoughts are. It seems like this is a replacement for something that already exists in ASIO. He may be happy to see this live in another library.
the functionality you need?
I'm not the only one who needs this functionality. I'm not the only one avoiding Boost.Fiber because integration with ASIO is problematic. I'm not the only one reinventing thread patterns and cancellation patterns on top of ASIO's completion token. Others are doing it independently.
I didn't say the functionality *only* you need. ;-)
Am Sa., 5. Jan. 2019 um 23:54 Uhr schrieb David Sankel via Boost < boost@lists.boost.org>:
- The dependency on C++11 (e.g. fiber objects are move-only handles just like thread objects). ASIO is a C++98 library. - Scope-creep within ASIO?
It seems like it would be a good idea to broach the subject with Chris to see what his thoughts are. It seems like this is a replacement for something that already exists in ASIO. He may be happy to see this live in another library.
If boost.asio would be C++11, the lib could simply migrate from boost. coroutine to boost.coroutine2 by changing the coro namespace. I guess that a separate library would make more sense.
participants (3)
-
David Sankel -
Oliver Kowalke -
Vinícius dos Santos Oliveira