I went with a 1 thread per rtsp client and regret it from a scaling perspective. The stack mem needed plus the overhead of having a thread gets to be too much when you get into a large amounts of streams.
The library is _very_ well written to be non blocking and given the speed of your slowest server CPU, you won't see any bottle necks with a single CPU. If I could do it all over again I'd code it to use n-clients per thread. Just NEVER write any blocking code on that thread. If you do need to delay a long running operation, simply re-enter the live555 message loop and set the watch var when done. Sent from my iPhone On Jul 27, 2012, at 4:27 PM, "Warren Young" <war...@etr-usa.com> wrote: > On 7/27/2012 5:07 PM, Ross Finlayson wrote: >> >> I'm >> puzzled by why so many programmers these days seem afraid (or unaware) >> to do this. > > I think it's a legacy of 1990s Windows and Mac OS: poor IPC, poor process > management, etc. But they had threads, which avoids the need for either. > > Now we've got a generation of programmers who didn't face the opposite > problem: bad or missing thread implementations, but excellent IPC and process > management, which encourages cooperative multi-process agglomerations. > > Tim, I recommend you read any book by W. Richard Stevens, and this: > http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf > > tl;dr on the latter: threads are mathematically proven to be evil. > _______________________________________________ > live-devel mailing list > live-devel@lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
