Re: [Boost-users] Understanding fibers

Subject: Re: [Boost-users] Understanding fibers
From: Stian Zeljko Vrba (vrba_at_[hidden])
Date: 2018-12-17 11:48:03

Hi,

Unfortunately, I can’t help you with fibers: I’ve went with coroutines https://www.boost.org/doc/libs/1_68_0/doc/html/boost_asio/overview/core/spawn.html not the least because it seems (! – I have to test this, I don’t fully trust the documentation on this) that exceptions can propagate nicely out of a coroutine handler and to the top-level event loop. According to the documentation, this isn’t the case for fibers, if an unhandled exception propagates out of the fiber’s stack frame, the program is terminated.

Though I have a comment/personal experience on this one:


  *   Well, to be honest, both solutions seem quite hacky and platform depend to me. Also, I have nowhere near the skills or time frame to implement this. Neither would I trust my solution. I'd rather trade in some performance and go for something a lot less perfect.

IME, platform-specific APIs _are_ the fastest way forward; you know what’s going on and there are no additional asio abstractions to code against.

// Rant

The project I’m working on started on Linux, and there you arguably need asio due to lack of proper async notifications from the kernel to the userspace, so the programming model there is just friendlier with asio (hah!). Now that I’ve fully migrated the project to Windows, I’m only waiting for the opportunity/time to rip out most of asio and use Windows native APIs.

.. when the state of C++ networking libraries has reached the point where it’s easier to code against raw windows API, something has gone wrong in the design of those libraries.

// Rant


  *   Stian

From: Boost-users <boost-users-bounces_at_[hidden]> On Behalf Of Stephan Menzel via Boost-users
Sent: Monday, December 17, 2018 11:20
To: Boost users list <boost-users_at_[hidden]>
Cc: Stephan Menzel <stephan.menzel_at_[hidden]>
Subject: Re: [Boost-users] Understanding fibers

Hello Stian,

On Mon, Dec 17, 2018 at 9:54 AM Stian Zeljko Vrba <vrba_at_[hidden]<mailto:vrba_at_[hidden]>> wrote:
Hi,

I’m jumping into the discussion, but I’ve noticed your concern here:

I’m in the process of implementing something similar, also with coroutines. On Windows, my plan for solving this is by creating a (native) autoreset event object and assign it to windows::object_handle. Then I use async_wait on the object. When the event object is signaled, the waiting coroutine will be resumed. So, in effect, this implements a non-blocking signal / “future”.

Yes, this seems like a good way of describing it.
I was gonna say something like asio::async_get_future(), which would take a fiber future or a regular one. This would fit perfectly. I could just run an io_service with one thread next to the async server and whenever the async server spits out a new request I could post it right into this io_service. The link Gavin posted, the way I understand it, pretty much describes the other end of this. An async operation that returns a future and I can wait on that on the outside.
Still, this page here: https://www.boost.org/doc/libs/1_69_0/libs/fiber/doc/html/fiber/integration/deeper_dive_into___boost_asio__.html made it clear to me that asio and fibers at this point cannot easily be used together without some real black magick.

On POSIX there are two ways, and both are hack-ish. You could use signal_set to wait for a specific signal (but signals + threads = UGH!, many pitfalls) or create an anonymous pipe; reading a byte from the pipe is equivalent to waiting on a signal object, while writing a byte to it is equivalent to setting a signal. Such pipe implements in effect an async-awaitable semaphpore.

Well, to be honest, both solutions seem quite hacky and platform depend to me. Also, I have nowhere near the skills or time frame to implement this. Neither would I trust my solution. I'd rather trade in some performance and go for something a lot less perfect.

I'm looking into spawning a thread in which I can spawn a fiber for each of the requests coming in and then use the fiber futures described earlier. My reasoning is that even though I cannot re-use them, spawning a fiber should still be faster than spawning a thread. A lock free Q of handlers could be used to post handlers into that thread. Have to figure out a way to prevent the starvation issue described in above link. They describe a situation when every fiber waits on a future, nothing is waking them up to poll new items from the hypothetical queue. Apparently, using a fast paced timer to ping them seems to be the way to go. Quite icky as well. Perhaps something more reasonable can be found, but I'm just rambling on here.

Thanks for your suggestion!

Stephan