|Anonymous | Login||01-22-2022 03:14 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Advanced Details [ Jump to Notes ]||[ View Simple ] [ 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|
|ETA||none||Fixed in Version||Product Version|
|Summary||0001576: [ENH] Socket exceptions ConnectionTimedOut and ConnectionClosed|
"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?"
|Steps To Reproduce|
|Attached Files||Socketsignalvariable.cs.gz [^] (754 bytes) 07-29-05 18:28|
(0002028 - 439 - 503 - 503 - 503 - 503 - 503)
"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
(0002029 - 183 - 183 - 183 - 183 - 183 - 183)
|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)
|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).|
|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.