Mantis Bugtracker

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0001576 [Squeak] Network minor always 07-29-05 18:26 12-10-05 21:05
Reporter KenCausey View Status public  
Assigned To gokr
Priority normal Resolution open  
Status assigned   Product Version
Summary 0001576: [ENH] Socket exceptions ConnectionTimedOut and ConnectionClosed
Description ajr <>:

"I'd like to propose a change to Socket to optionally raise
ConnectionTimedOut and ConnectionClosed on certain read operations.

For example, consider SocketStream>>#nextLine. It returns an empty string
on timeout, which is ambiguous with receiving an empty line. (I have also
seen this call repeatedly return an empty string when the other end has
closed the connection but the socket state doesnt yet reflect this).

It could be implemented with one of the following:

1) change #receiveDataTimeout:into:startingAt: to call #waitForDataFor:
which signals the exceptions, instead of

2) create new methods eg #receiveDataSignalTimeout:.... and update
appropriate sender(s) eg SocketStream>>#upToAll:

3) add an instance variable (eg signal or shouldSignal boolean) to a)
SocketSteam or b) Socket, and condition
#receiveDataTimeout:into:startingAt: to call either #waitForDataFor: or


1) simplest but raises compatibility issues. Returning quietly even with
 timeout specified, appears to be by design so this would be a design

2) increases Socket bloat, and still requires changes in possibly multiple
callers in eg, SocketStream. Compatibility issues again.

3) If shouldSignal was a variable, Socket wouldn't need so many method
signatures (ditto timeout for that matter).

3a) more consistent with timeout var, but like timeout would require new
method signatures to pass this state on the stack to Socket.

3b) can switch the behavior of clients to exception-raising without
requiring any new method signatures like in 2), or impacting existing
clients (ie, if var not set, works as currently).

Arguably the variable belongs to Socket; it controls Socket behavior
(again, ditto timeout); then it wouldn't have to be passed on the stack.
Is changing Socket shape problematic?"
Additional Information
Attached Files  Socketsignalvariable.cs.gz [^] (754 bytes) 07-29-05 18:28

- Relationships

- Notes
(0002028 - 439 - 503 - 503 - 503 - 503 - 503)
07-29-05 18:27

"The included changeset implements 3b) of the OP. It can be filed in with
Sockets open. It should have no effect whatsoever on any existing code.
However, if the new socket variable named 'signal' is set to true, then
calls to #receiveDataTimeout:into: startingAt: will signal exceptions by
calling #waitForDataFor: instead of

(attaching Socketsignalvariable.cs.gz)
(0002029 - 183 - 183 - 183 - 183 - 183 - 183)
07-29-05 18:29

I loaded this changeset into a 3.8-6665-basic image without errors. Although I did give the SqueakMap Package Loader a try (no obvious problems) I did not really test this changeset.
(0003269 - 154 - 154 - 154 - 154 - 154 - 154)
12-10-05 21:05

I just assigned this one to me - I will look at it but can already say that FastSocketStream with extensions to Socket may already have fixed this (IIRC).

- Issue History
Date Modified Username Field Change
07-29-05 18:26 KenCausey New Issue
07-29-05 18:27 KenCausey Note Added: 0002028
07-29-05 18:28 KenCausey File Added: Socketsignalvariable.cs.gz
07-29-05 18:29 KenCausey Note Added: 0002029
12-10-05 21:04 gokr Status new => assigned
12-10-05 21:04 gokr Assigned To  => gokr
12-10-05 21:05 gokr Note Added: 0003269

Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
44 total queries executed.
33 unique queries executed.
Powered by Mantis Bugtracker