[Live-devel] BasicTaskScheduler not reading fast enough?

[Ross Finlayson]

>I have spent a lot of time analyzing the SingleStep function in the 
>BasicTaskScheduler that I am using.  I added an optimization that 
>seemed to improve things slightly:  Basically, if the timeToDelay is 
>0 before the select, it means that there are "alarms" ready to 
>process (Which is usually the packets ready to send in 
>MultiFramedRTPSink).  In this case I call fDelayQueue.handleAlarm 
>immediatly.

The problem with this is that it can potentially lead to 'livelock' 
situations - e.g., if the handler of a 'delayed task' itself calls 
"TaskScheduler::schedulerDelayedTask()" to set up a new delayed task 
(especially if the 'delay' is zero).  That's why 
"BasicTaskScheduler::SingleStep()" always tries to handle at least 
one socket (and iterates through all the available sockets).


>I thought about creating my own TaskScheduler that iterates over the 
>all the sockets after the select has returned indicating there is 
>data ready on the sockets, rather than returning after processing 
>one socket.  Ross, any reason you did not do this in your original 
>implementation?  I think it would be to allow the watch variable to 
>be checked really frequently, correct?

No.  Note that our event loop code (in "BasicTaskScheduler") just 
calls "SingleStep()" in a loop.  This ends up doing exactly what I 
think you are asking for: iterating over all the sockets, and 
checking the watchVariable after each one.

In any case, remember that our event loop does nothing but handle 
events.  Playing around with the order in which the different kinds 
of event (readable sockets and delayed tasks) are handled can't 
overcome the fact that if events happen to be occurring faster than 
you can handle them, then you're going to have problems.

But of course, remember that "BasicTaskScheduler" is intended to be 
just that - basic.  you or anyone else is free to write their own 
"TaskScheduler" subclass specialized for your particular environment 
- if you think that will help (but note once again the previous 
paragraph).
-- 

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