<div dir="ltr"><div>Hi Ross,<br></div><div>I completely understand your position.</div><div>I just wanted to clarify the use case here: In our application, the end user decides when to SETUP and PLAY the stream which is presented to her/him after the DESCRIBE succeeded. It is also the end user deciding whenever to TEARDOWN the stream. Usually the end-user is not part of the event loop (i.e. on another UI thread).</div><div>That said, the recommended way to schedule the end-user requests on the event loop works well. <br>I just wanted to provide the patch in order to make it this use case more flexible and help out a little bit.<br></div><div>Thanks for your help,<br></div><div>Kind regards,<br></div><div>Lionel<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 10, 2020 at 12:29 AM Ross Finlayson <<a href="mailto:finlayson@live555.com">finlayson@live555.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">OK, so let me get this straight: You are doing something (calling LIVE555 code (beyond just “triggerEvent()”) from a thread outside the event loop) that you know is ‘unsupported’, and which you (should) also know could produce many race conditions that may cause your application to fail in unpredictable ways.  And you expect me to accept a patch that removes just one of these many possible race conditions that can occur if you do something that you shouldn’t be doing?<br>
<br>
Sorry, but I’m not going to be applying this patch.  <a href="http://www.live555.com/liveMedia/faq.html#threads" rel="noreferrer" target="_blank">http://www.live555.com/liveMedia/faq.html#threads</a> means what it says.  You should only be calling this code from the event loop.  If you do this, then - after the call to “write()” - the current code will always get to enqueue the request record before it ends up returning to the event loop to handle the response.<br>
<br>
What I don’t understand is why you even wanted to send RTSP commands from outside the event loop in the first place?  A RTSP command is usually sent only after handling a RTSP response, or after some time has expired - both of which are events that are handled within the event loop.  And if you want to open multiple RTSP stream (each with its own “rtsp://“ URL) concurrently, then you can easily do this within a single event loop, as illustrated by our “testRTSPClient” command; see the code at lines 77-80 and 182-184 in “testProgs/testRTSPClient.cpp”.<br>
<br>
<br>
Ross Finlayson<br>
Live Networks, Inc.<br>
<a href="http://www.live555.com/" rel="noreferrer" target="_blank">http://www.live555.com/</a><br>
<br>
<br>
_______________________________________________<br>
live-devel mailing list<br>
<a href="mailto:live-devel@lists.live555.com" target="_blank">live-devel@lists.live555.com</a><br>
<a href="http://lists.live555.com/mailman/listinfo/live-devel" rel="noreferrer" target="_blank">http://lists.live555.com/mailman/listinfo/live-devel</a><br>
</blockquote></div>