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).
OK - yes. If the fibers are not moved to other worker-threads this shouldn't be an issue - right? I read in some news-groups that at least on POSIX platforms the interaction between fibers and threads is not defined - maybe the post was related to the thread-specific stuff. regards, Oliver -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser