Anthony Williams:
Fibers are still tied to a particular thread, so thread-local variables and boost::this_thread::get_id() still return the same value for a nested task. This means that a task that calls future::get() might find that its thread-local variables have been overwritten by a nested task when it resumes. It also means that any data structures keyed by the thread::id may have been altered. Finally, the nested task inherits all the locks of the parent, so it may deadlock if it tries to lock the same mutexes (rather than just block if it is running on a separate thread).
No. If task A holds a mutex M and waits for task B, and task B tries to lock M, you have deadlock no matter which thread executes B. For the thread locals, they usually are altered in the manner they should've been altered, unless a task uses thread locals instead of ordinary locals and calls itself. Expecting errno to persist across a future wait (or across an arbitrary function call) is not a reasonable assumption. -- Peter Dimov http://www.pdplayer.com