[Live-devel] Design choice

[Jeremiah Morrill]

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" <warren at 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 at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>