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
