Hi,
while writing some SMS PDU parsing code I stumbled across an
"oddity" I have not seen with GNU Smalltalk. When calling the
>>#next: selector on a ReadStream and the number of elements
I need are not available, Pharo will return less or an empty
collection. This means I write code like this:
| id len |
id := stream next: 4
id size = 4 ifFalse: [^self reportError: 'Short read'].
len := stream next: 4
len size = 4 ifFalse: [^self reportError: 'Len not available'].
Besides the aesthetic issue it is getting worse when the SocketStream
class is in use. So now >>#next: 4 can return nil as well. But
naively I wrote code like this:
[
| msg |
msg := ThingParser parse: aSocketStream.
] on: ConnectionClosed do: [:e |
self logStuff: e.
self scheduleReconnect
]
So to make the above code work with the SocketStream I need to
write the following. I had a quick look at why the ConnectionClosed
is swallowed and found the comment to allow partial reads out of
a dead socket.
| id len |
id := stream next: 4.
id ifNil: [^self reportError: 'Short read'].
len := stream next: 4
len ifNil: [^self reportError: 'Short read'].
len size = 4 ifFalse: [^self reportError: 'Len not available']
In GNU Smalltalk there is EndOfStream which is a subclass of
Notification and the above code boils down to:
[
| id len |
id := stream next: 4.
len := stream next: 4.
] on: EndOfStream do: [:e |
self logStuff: e.
self scheduleReconnect.
].
So couldn't the >>#readInto:startingAt:count: selector of SocketStream
do something like GNU Smalltalk and give an EndOfStream notification?
[self receiveData: anInteger] on: ConnectionClosed do:[:ex|
EndOfStream signalOn: self.
ex return
].
kind regards
holger
