I split this reply into its own thread more in keeping with its topic. I've done some work on overlapped I/O and TBB using pipelines, but I'm struggling to grasp the technique you describe. The text mentions a parallel_for but the only code snippet is the read routine that employs a while (1). Is the parallelism in your one camera case done on a frame by frame? (I have not worked at all with OpenCV.)
The description you give of one stream not appearing until the window displaying the other stream is destroyed sounds like resource contention in the window-level display routines.
You might be able to handle two cameras in a TBB pipeline but to be fair, you'd probably want to interleave and mark the frames so as to be able to disambiguate them later. The mention of a face-detection algorithm suggests there is some processing involved. Is the per-frame processing uniform, or might there be load balance issues because ofvarying frame computational loads?
Yes the TBB task scheduler is non-preemptive and unfair (for example, letting tasks select their successors), its philosophical goal to keep threads executing on the processing element upon which they're currently resident for as long as they have local work to do(to maximize cache residence). This typically is not the policy you want in a scheduler that balances work among threads and processes that are doing I/O. It was unclear from your initial post what the relationship was between the parallel_for call and the while (1) loop or loops used for the video capture and display. Knowing that the infinite loop was inside the TBB parallel construct and knowing about the behavior of the TBB scheduler, it should be pretty clear what went wrong.
I'm glad you were able to figure out the source of the hangs and I look forward to your report on the details of your approach. Thanks for providing this update.