<html><body><P>Dear Ross (and anybody),</P>
<P>I followed all the posts about threading and event loops some days ago. I also reviewed the FAQ once more and because I had done it several times in the past, it seems to me that the recommendation "Such a configuration is not recommended, however; instead, it is safer to structure such an application as multiple <EM>processes</EM>, not multiple threads." has been added recently and was not there just some weeks ago. Am I right?</P>
<P>When this configuration (more event loops running in separate threads with dedicated usage environments and task schedulers) is not recommended any more, it is bad news for us because our application is structured exactly in this configuration. Nevertheless, we have not seen any problems in this configuration so far, in our tests we are running up to 20 threads in one process, each thread is responsible for exactly one RTSP server. Could you, please, be more specific why this configuration is not recommended? Are there any known problems with this configuration? (I think the problem can be some static variables but since we compiled the live555 code to a Windows COM library and create one instance of a COM object for each RTSP client, maybe the static variables are not touched by other instances, but I am not sure about this).</P>
<P>Finally, according to my opinion, this approach is far better than having just one thread to be responsible for many RTSP servers because the code contains blocking operations and it can easily happen that longer response times or a low speed network connection of one RTSP server can have a negative impact on the video streams from other RTSP servers or am I completely wrong?</P>
<P mce_keep="true">Best regards and thanks very much for your answers</P>
<P>Alex</P>
<P mce_keep="true"> </P>
<P mce_keep="true"> </P></body></html>