[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
|