Hi Ross, I completely understand your position. 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). That said, the recommended way to schedule the end-user requests on the event loop works well. I just wanted to provide the patch in order to make it this use case more flexible and help out a little bit. Thanks for your help, Kind regards, Lionel
On Thu, Dec 10, 2020 at 12:29 AM Ross Finlayson <finlay...@live555.com> wrote: > 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? > > Sorry, but I’m not going to be applying this patch. > http://www.live555.com/liveMedia/faq.html#threads 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. > > 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”. > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > _______________________________________________ > live-devel mailing list > live-devel@lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel >
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
