[Live-devel] Overuse of CPU in binaries of CYGWIN

[Warren Young]

On 2/24/2014 06:36, Martínez Contador, Daniel [ELIMCO] (CA) wrote:
>
> This is an educated guess. In Cygwin the RTSPClientConnection
> socket doesn't close explicitly after a TEAR. The read bitmask
> in the call to select in BasicTaskScheduler remains active
> and the call returns immediately by some reason which doesn't
> apply to other posixes.

If the remote peer closes a TCP socket, select() will mark it readable, 
because it wants you to call recv() one last time and get -1, which is 
how BSD sockets (and Winsock) signal that condition.

In a program that never makes that last recv() call, select() will 
continue to mark that socket readable forever.  This is a popular way to 
get into an infinite loop.  I'd be surprised if Live555 makes this 
mistake, because it isn't Winsock specific.  If Live555 has this bug, it 
should affect BSD sockets based systems, too.

Please post your patch, so we can see if this is indeed the problem it 
fixes.

Winsock semantics are pretty darn close to BSD sockets semantics.  Once 
upon a time, in a galaxy far far away (on the t axis) Winsock had a 
64-bit socket limit that affected Cygwin, too.  That was fixed about 15 
years ago in Cygwin, and earlier in Microsoft native stacks.

Cygwin still defines FD_SETSIZE to 64 by default, and Live555 doesn't 
override it.  This does mean that a default build of Live555 on Cygwin 
won't be able to open more than 64 sockets.  Since you eat 3 for stdio 
and each RTSP connection takes 3 (one for RTSP and one each for audio 
and video RTP) this means you will run into trouble with RTSP with only 
21 simultaneous RTSP streams.

Ross, you should say "#define FD_SETSIZE 1024" or similar #ifdef _WIN32.