Boost logo

Boost :

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

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

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.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at