Hello Stian,

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