[squeak-dev] Re: Socket clock rollover issues

Andreas Raab andreas.raab at gmx.de
Wed Apr 29 01:24:56 UTC 2009


Nicolas Cellier wrote:
> I wonder why you adopt a soft busy loop like this:
> 	"Wait in a soft busy-loop (500ms) to avoid msecs-rollover issues"
> 	self writeSemaphore waitTimeoutMSecs:
> 		(deadline - Time millisecondClockValue min: 500 max: 0)

Heh. You are asking about my dirty little secrets ;-) The reason for 
writing the loop that way is that I have (mounting) evidence that at 
times we may loose signals originating from external semaphores. We have 
seen situations where external signals apparently weren't delivered even 
though the condition was clearly set on the underlying socket. This is 
not only true for sockets but we have seen other situations when 
external semaphore signals apparently have been delivered.

Unfortunately, I have not been able to fully understand this problem and 
when or why it happens. All I can say at this point is that there is 
evidence to suggest that at times signals may not be delivered. The code 
is written in the way you see purely as a defensive measure against such 
effects - it actually had been rewritten that way before I fixed the 
rollover problems and it just fit in nicely with the rest of it.

> And then, since Process swap should not happen in a forward branch, a
> msecsEllapsed  variable could also be used:
> waitForSendDoneFor: timeout
> 	"Wait up until the given deadline for the current send operation to
> complete. Return true if it completes by the deadline, false if not."
> 
> 	| startTime msecsDelta msecsEllapsed sendDone |
> 	startTime := Time millisecondClockValue.
> 	msecsDelta := (timeout * 1000) truncated.
> 	[self isConnected & (sendDone := self primSocketSendDone: socketHandle) not
> 			"Connection end and final data can happen fast, so test in this order"
> 		and: [(msecsEllapsed := Time millisecondsSince: startTime) <
> msecsDelta]] whileTrue: [
> 			self writeSemaphore waitTimeoutMSecs: msecsDelta - msecsEllapsed].
> 
> 	^ sendDone
> 
> Unless I missed something, this code look simpler.

Yes, that looks indeed much nicer. I don't know if you want to include 
the upper wait limit - it somewhat depends whether you think you might 
be loosing signals or not.

Cheers,
   - Andreas



More information about the Squeak-dev mailing list