[Live-devel] non blocking sockets

[Ross Finlayson]

>  > >I noticed that in the library the RTSPServer as well as the RTPSink
>>  >makes use of only blocking read/write system calls.
>>
>>  That's not true.  Both the TCP sockets (for RTSP control) and UDP
>>  sockets (for RTP) are set up as non-blocking.
>
>you are right, they are setup as default non-blocking,
>anyway the real use seems to be blocking.
>I mean:
>The RTSPClientSession receives from the RTSPServer a non blocking 
>TCP socket. Then in the incomingRequestHandler1()
>it calls the readSocket (with NULL timeout parameter).
>The readSocket calls the blockUntilReadable() and this function does 
>a select() with a single file descriptor (the socket) in its fdset.
>I think that this blocks the process.
>Do you agree?

No, because the sockets get read only when new readable data becomes 
available (within the event loop).  (This is what the calls to 
"TaskScheduler::turnOnBackgroundReadHandling()" do.)  Because of 
this, the socket reads end up being non-blocking, because they are 
called only when new data is available.  (In this case, the 
"blockUntilReadable()" call doesn't actually 'block'; blocking 
happens only if a socket is read when no incoming data is actually 
available (but the RTSP server code never does that).)
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/