[Live-devel] Question about Recursive TaskScheduler::doEventLoop Call

[Mit Shan]

> Note that "GenericMediaServer::lookupServerMediaSession” is part of the library code, and thus is not meant to be modified.  Instead, you should subclass “RTSPServer”, and reimplement the virtual function “lookupServerMediaSession” in your subclass.  (This is what we did for the “DynamicRTSPServer” code in the “mediaServer” directory.)

Yes, I intent to use live555 library by standard "extending" way. I have 
already extend "RTSPServer" class to redefine my 
"lookupServerMediaSession" method, if I didn't express it clearly.

> But perhaps we should step back and ask why you want to block within your implementation of “lookupServerMediaSession”?  What are you trying to do here?

Since I want to use the library to build a live/playback streaming 
server with database and other third-party SDK into it. When handling 
"lookupServerMediaSession", I may 1) query the database 2) call some 
functions in third-party SDK to get video stream (which may use class 
"DeviceSource" later). And I can't assume operation 1 and 2 will not 
block (And I think even 100 ms block is not tolerant), since database 
query may slow down because of network conditions, and third-party SDK's 
non-blocking can't be counted on.

I once wanted to put these operations after RTSP "PLAY" succeeds, but 
when errors occur when doing my stream setup stuff, I lose the chance to 
response with an error code in RTSP protocol, such as "404 File Not Found".

> Yes.  Unfortunately, the “lookupServerMediaSession” function was meant to be synchronous, so the only way that I can see for it to ‘block’ (handling events) within its implementation is to (recursively) call “doEventLoop()” with a 'watch variable' parameter.  This does have the problem that you noted - that if there are subsequent calls to “lookupServerMediaSession” within this event loop, then handling will be LIFO - but I don’t see any alternative.
And now I still have a possible option: implementing a event-pool 
"TaskScheduler". But I worry whether this is feasible, since the whole 
library is designed basing on event-driven with one thread. What's your 
advice to this idea, or is there any pioneer? (And if event pool is 
finally feasible, using Boost.Asio to accomplish the task may work.)


Mit Shan.