This is probably the most naive reply ever, so I'll keep it brief.

I could imagine that on creation, a UUID could be created using boost::uuid. Using boost::interprocess, the fiber_manager could be put into a named shared memory, the name of which is the UUID. The UUID is then passed to any fiber upon creation so that all it needs to do is open the named interprocess pool to access the fiber_manager.

A big redesign? Maybe, I haven't looked at the library. But maybe there is something of value in that concept. I have had to do something similar and more complex myself recently to update legacy 16-bit code that migrated things between processes that it shouldn't have.

On 9/6/2015 4:19 PM, Nat Goodspeed wrote:

Oliver has requested help overcoming the TLS optimization/bug. It
would be wonderful if one of you requesting support for fiber
migration would be willing to suggest a way for a given fiber to
robustly locate the fiber_manager, and so forth.