Oliver Kowalke wrote:
Boost.Fiber is modeled after the interface of Boost.Thread and this API is at least for me more convenient than co-routines (that means I'm more familiar with the usage of threads) and Boost.Fiber was written for support of Boost.Task (non-blocking tasks inside the thread-pool).
I don't think that the libs should be merged.
Code that uses fibers can be somewhat gnarly by necessity, especially when exception handling and multiple platforms are thrown in to the mix. For example, I found that MinGW GCC's older SJLJ mechanism is particularly problematic (http://lists-archives.org/mingw-users/09843-bug-with-win32-fibers.html), though I suspect you're far more qualified to work around that than I, if you haven't already. Anyway, should boost really have two lots of code for this stuff? In other words, would it not be beneficial if one library was written in terms of the other? Kind regards, Edd