[FIX] Socket accept handling

Stephen Pair stephen at pairhome.net
Tue Jul 29 13:35:46 UTC 2003


Luciano Notarfrancesco wrote:

> Hi Stephen,
>
>> waitForAcceptFor: timeout
>> waitForAcceptFor: timeout ifTimedOut: timeoutBlock
>> waitForConnectionFor: timeout
>> waitForConnectionFor: timeout ifTimedOut: timeoutBlock
>> waitForDataFor: timeout
>> waitForDataFor: timeout ifClosed: closedBlock ifTimedOut: timedOutBlock
>>  
>>
> What's the point of the *ifTimedOut: and *ifClosed:ifTimedOut: 
> messages? Wouldn't it be better to implement only waitFor*For: and 
> encourage people to use exceptions? 


I liken it to the at:ifAbsent: pattern...yes, exceptions are good, but 
for many common scenarios when you are interested in a very explicit 
condition using #at:ifAbsent: is much more intention revealing than:

    [someObject at: X] on: KeyNotFound do: [ :ex | self doSomething ]   
"This of course assumes the we have a KeyNotFound"

Similarly, I prefer:

aSocket waitForConnectionFor: 10000 ifTimedOut: [ ^self  error: 'could 
not reach the server']

Over:

[aSocket waitForConnectionFor: 10000]
    on: ConnectionTimedOut
    do: [ :ex | ^self error: 'could not reach the server' ]

Of course, you can use either form with this change set.  


>>     [Time millisecondClockValue < deadline]
>>  
>>
> I think this might cause problems with clock rollovers. Take a look at 
> Time|millisecondsSince:


Well, I didn't write this code, but yes, there would be issues around 
rollovers...particularly if your deadline was very close to SmallInteger 
maxVal.  One thing that could be done is to check that the current clock 
value is not less than the original clock value when the deadline was 
calculated.  In the other case where the deadline is past the rollover, 
you could check that the current clock value has not rolled over, and if 
not, consider it to be under the deadline.  Of course, a rollover only 
happens approximately once every 12.4 days, so it will be very rare to 
have problems...but to be safe, we should not allow deadlines that are 
more that a few days in the future (to prevent problems with multiple 
rollovers).  These algorithms should be wrapped up nicely in the Time class.

- Stephen



More information about the Squeak-dev mailing list