Re: [boost] [boost.fiber] regarding to migration of fibers between threads?!

Subject: Re: [boost] [boost.fiber] regarding to migration of fibers between threads?!
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-01-12 09:55:24

On 6 Jan 2015 at 19:38, Oliver Kowalke wrote:

> boost.fiber was reviewed in January 2014 and now I've finished the
> requested changes. Unfortunately the migration of fibers between threads
> is not stable yet, but synchronizing fibers running in different threads
> works. 
>
> I'd like to know if fiber migration is absolute necessary to pass the
> next review or might it be acceptable to finish this feature later. 

Firstly Oliver my apologies for taking so long to reply to this. I 
hadn't attended to Boost email in a week, so I ended up emailing you 
privately to ask what this email already answered.

One probably fairly common use case will be Fibers inside ASIO 
strands, and ASIO strands do not guarantee that the same thread will 
execute strand work, only that no work in the same strand will be 
executed concurrently.

An entirely viable alternative to implementing fiber migration is a 
new type of "fibre strand" which is API compatible with ASIO strands. 
Such a fibre strand would use an ASIO io_service to run itself, and 
might relocate a fibre strand across threads if, and only if, no 
fibres are currently suspended in a given strand. This would load 
balance fibre strands across available kernel threads probably quite 
well.

In terms of what AFIO would need from Fibers, AFIO is in the unusual 
situation that at least some filing system calls have to be 
multiplexed across kernel threads because no operating system 
provides a complete asynchronous file API apart from QNX and the 
Hurd, so Fiber support in AFIO would be easiest if I can invoke a 
completion fiber from whichever kernel thread completes the kernel 
API. Of course, one doesn't need to actually execute the fiber there 
and then, one I would assume simply do a promise.set_value() and the 
fiber will resume wherever it is currently executing. However if 
Fiber had the ability to easily migrate fibers, it might be optimal 
to execute the fiber handler immediately at the point of 
promsise.set_value().

Just to FYI my future timetable, AFIO develop branch is now BindLib 
based, and therefore lets the end user select any threading, 
filesystem and networking implementation of their choice so long as 
it provides the STL API. My current hope is that adding Fiber support 
to AFIO will be as simple as making afio::future<> Fiber aware. 
afio::future<> won't be in the v1.3 release intended for later this 
month, but afio::future<> is pretty much the core new feature for the 
v1.4 release intended for the next release.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/