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/