<div>> Instead, you should be using a single event loop (in a single thread) <br></div><div>> - even to make multiple RTSP client requests.<br></div><div></div><div>Yes I know, but I have a few reasons to do it in multiple threads:</div>
<div></div><div>You have to take into account that there is a limit on the number of sockets in a single FD_SET on most systems. On some systems the limit is only 64 sockets. So when you have an separate socket for RTSP, RTCP, RTP-audio and RTP-video you can open 16 sessions at most. Safe limit would be rather about 8 sessions, I think. </div>
<div></div><div>From what I found out RTSP client uses blocking calls and when it's sending requests it is blocking other sockets, so you can loose video or audio frames in other connections. It is undesirable effect if you are often creating and destroying RTSP sessions. </div>
<div></div><div>When you have a multi core processor it is a good programming practice to create a one thread per core and spread all sessions between all available threads. Of course I didn't implement a multithreaded scheduler or something. I know that LiveMedia don't support thread pool architecture ( and thanks God, it looks good and fancy in academic books but it's debugging hell and you probably loose more trying to synchronize access to session data or even queue than gain from using multiple threads ).</div>
<div></div><div>I saw your comment in code regarding making CSeq static. If there is a problem with other usage scenarios you can always move CSeq to BasicEnvironment class. It would be one CSeq variable per thread in that case.</div>
<div></div><div>Thanks for all answers,</div><div>Adam</div><div></div><div></div>