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
