Re: [Boost-users] Understanding fibers

Subject: Re: [Boost-users] Understanding fibers
From: Stephan Menzel (stephan.menzel_at_[hidden])
Date: 2018-12-17 10:20:20

Hello Stian,

On Mon, Dec 17, 2018 at 9:54 AM Stian Zeljko Vrba <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