This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: Delay after Delay Feed Title: Travis Griggs - Blog Feed URL: http://www.cincomsmalltalk.com/rssBlog/travis-rss.xml Feed Description: This TAG Line is Extra Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Travis Griggs - Blog

Delays are the theme. Delay is a fun class to explore. I'm always surprised how "simple" it actually is. Delay instances reify a resumption time, a state indicated whether they are active or not, and finally a semaphore which is used to actually do the blocking of a process that wishes to wait on a delay. Delay class manages the actual execution of "active" delays (i.e. delays that are being currently waited on).

The only "real" delay in the system is managed by the VM. A singular semaphore (TimingSemaphore) is registered with the VM. Each time a Delay becomes active, it finds the active delay that comes due earliest, and tells the VM to kick the TimingSemaphore at that time. That delay becomes the ActiveDelay, all other active delays are kept in a SortedCollection called SuspendedDelays. The process that "activated" the delay then goes to sleep by waiting on the delay's internal semaphore. When the VM timer comes due, it kicks the TimingSemaphore. The singular TimingProcess loops indefinitely waiting on this semaphore. Each time it gets past the TimingSemaphore, it basically grabs the ActiveDelay, sets it to done, signal's its internal semaphore (which will allow the process blocked on it to come back awake, once this TimingProcess goes back to sleep) pulls the front delay out of the SuspendedDelays queue as the new ActiveDelay, informs the VM when the next "kick" is to come. Pretty straightforward actually.

So I had this idea. I had a process which was waiting on a delay, but in some cases, a condition arose which caused me to want to have the delay "wait a little longer yet". You can't do this directly with the existing Delay APIs, but you can piece together your own copying from the others. Something like:

waitMoreSeconds: aSeconds 
	resumptionTime isNil ifTrue: [self error: 'No resumption time'].
	resumptionTime := resumptionTime 
				max: Time microsecondClock + (aSeconds * 1000000) truncated.
	
	[AccessProtect critical: 
			[delayInProgress 
				ifTrue: 
					[SuspendedDelays add: ActiveDelay.
					SuspendedDelays reSort.
					ActiveDelay := SuspendedDelays removeFirst activate]]] 
			valueUnpreemptively

Obviously, this won't work on a delay that is not already waiting. Once that's out of the way, we recompute the resumption time as now + more. The novel part of this action, is that we are not starting or terminating an existing delay, but rather modifying an already existing one. So we place the ActiveDelay back in the SuspendedDelays, resort it, because our receiver may move around in the SuspendedDelays list now. And then reactivate the appropriate one, just as if the TimingLoop had done it.

In the end, after I got this working, I found a different way to do it for my particular use case. But I still thought it was cool. And who knows, maybe in the future (play on words, haha) it'll come in handy.