Dear Ross, Thanks for your reply. Well, I do understand your point. That was why I tried to explain every solution that came to my mind and all were not right for my case.
About the first solution to run each one in a separate process, all the controlling is not killing a process or the like. I am recording files from incoming RTSP connections, and whenever I am done with a file I want the parent program know about that, so I call a callback function. Or whenever there is a connection error or any type of error, I want to handle the error by letting the main program know about that and resolve the issue. I also need to stop the RTSP connection neatly, and not to just KILL the process. I ask the connection to stop (anytime the user asks me to) and it will wrap everything up and close any open connections and files. And many more. If I use multiple processes, I would need to use inter process communication or something like that, and that is not right. The right solution is to do like something done in the testRTSPClient test project. I am doing that and it seems to be working fine. BTW, I am not afraid of using multiple processes. I use such a solution, when I need to. But sometimes you need to have control over your own program and interact with your program, rather than giving everything to the OS. I know the idea for openRTSP was to be used as an stand alone program and to be used in a shell-script. I also think that it is the best solution for such applications. I just simply asked a question here, to see if anybody has taught about it before or not (although I have seen old emails about the same issue, with the answer to use shell-scripting). Again, thank you all very much, for this great library and all your great efforts. Regards, Ehsan On Mon, Jan 6, 2014 at 1:51 PM, Ross Finlayson <[email protected]>wrote: > I am trying to use the openRTSP code in my program and use it to record > from multiple sources at the same time. Therefore, I need to run each > instance in a separate thread. > > > No, the second sentence does not follow logically from the first. (See > below.) > > > But openRTSP code is not thread safe (many global variables). I will be > left with three options: > 1- To run openRTSP as a stand-alone process for each client stream. > > > Yes, that is what you should do. E.g., use a shell script to exec > multiple "openRTSP" commands concurrently. > > This would not be efficient, and I would lose control over each openRTSP > running process. > > > No, this would still be efficient, and you could easily control each > "openRTSP" process, from your shell script. E.g., your shell script could > note the pid of each "openRTSP" process, so it can kill them, if necessary. > > I continue to be surprised how - in this century - so many programmers > have become afraid of (or unaware of) structuring applications as multiple > processes, resorting instead to using multiple threads within a single > process - which is *much* more difficult, and *much* more error-prone (and > is something that's required only when you need shared memory). > > > 2- To re-implement openRTSP with a same scheme as in testRTSPClient test > program. Creating my own StreamClientState, ourRTSPClient and DummySink > classes. But I would lose all the functionality implemented in openRTSP. > Implementing every one of them would be hard. > > > You wouldn't need 'all' the functionality of "openRTSP" - just the parts > that you want. But in any case, I don't recommend that you do this, unless > you need only very basic functionality of "openRTSP". (Especially as this > is a hobby for you.) > > > 3- Try to make the current openRTSP implementation thread-safe, by > defining StreamClientState and putting all global variables in playcomm.cpp > in that class and trying to over ride RTSPClient used there. But the > RTSPClient is initiated in the HandlerServerForREGISTERCommand and finding > the correspondences is a bit hard. > > > No, I don't recommend that you do this. The "openRTSP" code is very > complex (in part because it's also used for "playSIP" - a SIP client). > It's not something to mess with. > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > _______________________________________________ > live-devel mailing list > [email protected] > http://lists.live555.com/mailman/listinfo/live-devel > >
_______________________________________________ live-devel mailing list [email protected] http://lists.live555.com/mailman/listinfo/live-devel
