I'm not an expert on networking stuff, but I'll try (and if I'm wrong I'll learn something new)... Holger Hans Peter Freyther wrote:
Classic ReadStream in Pharo3.0
#[] readStream next: 2 => #[]
SocketStream:
1.) Start something that listens to 12345 $ nc -l -p 12345
2.) In Pharo do
| conn | conn := (SocketStream openConnectionToHostNamed: 'localhost' port: 12345) binary; noTimeout; yourself. [ (conn next: 4) inspect. ] on: ConnectionClosed do: [:e | "Never called" self halt ].
3.) CTRL+C the netcat process.. 4.) In Pharo an inspector on an ByteArray is coming up. The ConnectionClosed signal is raised but swallowed by the SocketStream code.
I don't know how realistic it is but I would appreciate if
1.) #[] readStream next: 4. Could raise an Error that one can not consume four bytes/elements.
Making it an Error seems a somewhat fundamental change that could break other people's code. Would a Notification be sufficient?
2.) I understand that not raising "ConnectionClosed" is to allow a partial read from the socket. What is done in GNU Smalltalk is to at least signal an EndOfStream notificaton. So the socket code could read like:
Are you implying that in the same situation GNU Smalltalk similarly does not raise ConnectionClosed, but raises EndOfStream instead? EndOfStream as a Notification seems a low impact addition that would be generally useful. Can you determine the code changes required for SocketStream? The fastest way to get what you need is to open a ticket at pharo.fogbugz.com, then also supply the required code** as a slice :). This will provide something concrete to review. **Including tests, one test that catches your new Notification, and then a duplicate of that test that does not catch the Notification, which works the same before and after slice is applied. cheers -ben
| conn | conn := (SocketStream openConnectionToHostNamed: 'localhost' port: 12345) binary; noTimeout; yourself. [ (conn next: 4) inspect. ] on: EndOfStream do: [:e | self handleClosing ].
is this more clear?
holger