[Live-devel] Blocking vs Non-Blocking doGetNextFrame()???

[Ross Finlayson]

>According to the DeviceSource.cpp template, the doGetNextFrame() 
>should deliver a frame "in a non-blocking fashion i.e., so that we 
>return immediately from this function even if no data is currently 
>available."
>
>However, if no data is available, the afterGetting() function is not 
>invoked within doGetNextFrame (since no new data is delivered) and 
>this causes the doGetNextFrame() function never to be called again 
>by the internal live555 API.  Any suggestions on how this problem 
>should be handled?

When the new data does arrive - later - it must be handled as an 
'event' - i.e., within the event loop.  The event handler can then 
call "doGetNextFrame()" again.

Unfortunately there's no one standard way of handling the arrival of 
new data as an 'event', because it depends on your particular 
environment (in particular, the nature of your input device).  If 
your input device can be treated as an open file, then it's easy, 
because you can use the event loop's existing "select()" mechanism.

If, however, your input device cannot be treated as an open file, 
then you have to do something else to handle the arrival of new data 
as an 'event'.  Some people use the optional "watchVariable" 
parameter (to "TaskScheduler::doEventLoop()") for this purpose. 
(Others may subclass "TaskScheduler" to implement their own event 
loop, although that is more difficult.)
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/