[Pharo-project] SocketStream>>atEnd
Hello guys, today, by examining closely the #atEnd implementation , i came to conclision that is can be made as simple as: atEnd ^ self isDataAvailable not Because, take a close look at old implementation: atEnd self isInBufferEmpty ifFalse: [^false]. ----***--- ^self isConnected not and: [self isDataAvailable not] and: isDataAvailable self isInBufferEmpty ifFalse: [^true]. ---***--- ^socket dataAvailable ifFalse: [false] ifTrue: [self receiveDataIfAvailable; isDataAvailable] a Socket>>dataAvailable answers false on closed or invalid socket. You can check it quite simply: (SocketStream openConnectionToHostNamed: 'google.com' port: 80) socket closeAndDestroy dataAvailable (SocketStream openConnectionToHostNamed: 'google.com' port: 80) close socket dataAvailable Socket new dataAvailable => all 3 answer false Therefore, a complex logic in #atEnd, could be simplified. Please, try to find a flaw in my conclusions. I think there's not. But 2 (or more) heads always better than 1. -- Best regards, Igor Stasenko AKA sig.
It appears that im wrong. sorry for disturbing :) 2010/1/15 Igor Stasenko <siguctua@gmail.com>:
Hello guys,
today, by examining closely the #atEnd implementation , i came to conclision that is can be made as simple as:
atEnd  ^ self isDataAvailable not
Because, take a close look at old implementation: atEnd     self isInBufferEmpty ifFalse: [^false].  ----***---     ^self isConnected not         and: [self isDataAvailable not]
and: isDataAvailable
    self isInBufferEmpty ifFalse: [^true].  ---***---     ^socket dataAvailable         ifFalse: [false]         ifTrue: [self receiveDataIfAvailable; isDataAvailable]
a Socket>>dataAvailable answers false on closed or invalid socket. You can check it quite simply:
(SocketStream openConnectionToHostNamed: Â 'google.com' port: 80) socket closeAndDestroy dataAvailable (SocketStream openConnectionToHostNamed: Â 'google.com' port: 80) close socket dataAvailable Socket new dataAvailable => all 3 answer false
Therefore, a complex logic in #atEnd, could be simplified.
Please, try to find a flaw in my conclusions. I think there's not. But 2 (or more) heads always better than 1.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
Igor Stasenko wrote:
It appears that im wrong. sorry for disturbing :)
...but thanks for digging in the SocketStream code! It was quite a while since I wrote it :) While we are at it we should improve the primitive for searching in String/ByteArrays to include at stopAt: argument. This would increase speed and simplify the horribly tricky logic in the upTo: family of methods in SocketStream. The reason for the trickiness is the fact that the search primitive always searches to the very end of the buffer (there is no stopAt: parameter) AND the buffer can of course include old data after the current end marker in which we may find "false hits". I remember the pain in writing that code... regards, Göran
participants (2)
-
Göran Krampe -
Igor Stasenko