[Live-devel] select() timeout parameter inside BasicTaskScheduler::SingleStep()

[Ross Finlayson]

>Could you help me to understand the use of fDelayQueue in
>BasicTaskScheduler::SingleStep(unsigned maxDelayTime) ? For each call to
>fDelayQueue.timeToNextAlarm(), the returned timeToDelay I get is larger than
>1 million seconds...

That happens only when there are no pending tasks in the delay queue.

>  This implies that tv_timeToDelay.tv_sec is then always
>set to MAX_TV_SEC (= one MILLION of seconds), and so never to the
>maxDelayTime paramater passed in SingleStep(). Why ? Did I miss something ?

Yes, you missed the fact that the test against MAX_TV_SEC is done first, 
and then the test against "maxDelayTime" (if "maxDelayTime" is not 0) is 
done next.  The net effect is that "tv_timeToDelay" is set to the minimum of:
         1/ fDelayQueue.timeToNextAlarm()
         2/ MAX_TV_SEC
         3/ "maxDelayTime" (if "maxDelayTime" is not 0)

Note, BTW, that the default value of "maxDelayTime" is 0, which means that 
this parameter is usually never used.  It is intended only for people who 
want to write their own subclass of "BasicTaskScheduler" (or 
"BasicTaskScheduler0") that limits the maximum length of time that each 
call to "SingleStep()" can block - e.g., because they want to do some 
additional polling within the event loop.

>  Then, I think there is a bug in the current computation of the timeout
>parameter of select()... The following test :
>(tv_timeToDelay.tv_sec*MILLION+tv_timeToDelay.tv_usec) > (long)maxDelayTime
>can not be right if the tv_timeToDelay.tv_sec value is equal to one MILLION
>because in this case tv_timeToDelay.tv_sec*MILLION will exceed the max value
>of a 4 bytes long. Am I right ?

Yes.  This will be corrected in the next software release.  (Note again, 
though, that this is an issue only if "maxDelayTime" is not 0 (its default 
value).)


	Ross Finlayson
	LIVE.COM
	<http://www.live.com/>