Hi Andreas,
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)

Wouldn't this one do the trick, since Delay itself can handle rollover ?
	self writeSemaphore waitTimeoutMSecs:
		(msecsDelta - (Time millisecondsSince: startTime) min: msecsDelta max: 0).

Keeping this (deadline := startTime + msecsDelta) is a bad idea, since
it can be a LargeInteger, and (deadline - Time millisecondsClockValue)
will stay > 0 forever in this case.
By replacing this piece of code, I think I do not need the rollover protection.

Beside, since startTime := Time millisecondClockValue,
(Time millisecondsSince: startTime)  is guaranteed >= 0 and <=
SmallInteger maxVal
Thus, protection can be:
	self writeSemaphore waitTimeoutMSecs:
		(msecsDelta - (Time millisecondsSince: startTime) max: 0).

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.

Nicolas

2009/4/28 Andreas Raab <andreas.raab at gmx.de>:
> Hi -
>
> I'm not sure anyone cares about this (most likely Seaside users), but class
> Socket has some issues with clock-rollover which can be seen on high load
> servers that have enough uptime and load.
>
> The problem is caused by Socket>>deadlineSecs: which at the time of the
> clock rollover computes a deadline that can never be reached. If you've seen
> connections that wouldn't time out apparently at random there is a chance
> you have been affected by this type of issue.
>
> Bug (and fix) are posted at http://bugs.squeak.org/view.php?id=7343
>
> Cheers,
>  - Andreas
>
>