All of that functionality is available from HPX. It gives you work-queue based scheduling (with work stealing) of suspend-able/resume-able threads (i.e. supporting yield) with very little overhead. It also manages the 1:N or N:M threading for you.
You could try building all of your functionality on top of HPX first. This could allow to figure out the actual underlying mechanisms your library would rely on. Later on you can move it to Boost after all of the required functionality has been accepted there.
Thanks for the further encouragement. I'll definitely take a closer look at HPX in the future. However, the deadline of GSoC is closing in, I have to found a simpler solution for now. Hopefully, having a more solid base will enable us to build something truly great later.
I understand your situation, and everything very much depends on your GSoC mentor.
From my perspective however, even if your GSoC is related to Boost, it is not necessarily required for your project to produce a ready-made Boost library. If in the end you coined out a functional interface with a proof of concept implementation, all of that combined with a clear understanding what facilities you would need in Boost or in the library, then you would have achieve your goal. HPX is an existing library which could help you with reaching that goal as you wouldn't have to worry about the underlying functionality. But that's just my - possibly biased - 2c.
Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu