FastSocketStream
Florian Minjat
flo.minjat at free.fr
Thu Sep 8 15:04:17 UTC 2005
With this change, it works well :)
Thanks!
Florian
goran at krampe.se wrote:
> Hi!
>
> Since this smelled like an FastSocketStream issue I looked into it - and
> found the issue:
>
> Jecel Assumpcao Jr <jecel at merlintec.com> wrote:
>
>>Marcus Denker wrote on Wed, 7 Sep 2005 17:31:40 +0200
>>
>>> -> FastSocketStream replaced SocketStream... you could file in
>>> the SocketStream from 3.8 to see if this makes a difference.
>>
>>I started having problems in Celeste so decided to load FastSocketStream
>>into the 3.8 image I am typing this in, but things stopped working
>>entirely (probably the ConnectionTimedOut: error, but I am not sure). I
>
>
> In fact, first I thought this could have to do with the fact that FSS
> (if you read the class comment) signals ConnectionClosed and
> ConnectionTimedOut exceptions, which can affect old client code (which
> should be fixed IMHO).
>
> A "hack" to get the old and faulty behavior - send "shouldSignal: false"
> to the stream.
>
> But... nah, then I started looking at the complex looking upToAll:
> method (we need a new prim btw to make it better!) but eventually found
> the much simpler cause in #sendCommand:. It doesn't flush. Oops.
>
> So change it to:
>
> sendCommand: aString
> self nextPutAllFlush: aString, String crlf
>
> After that it seems to work (you can test using a filelist, click at
> UIUC on the bottom).
>
>
>>On the other hand, I loaded FastSocketStream into a 3.8 image with
>>Seaside and it was a huge improvement there and has worked perfectly for
>>a couple of months now.
>
>
> Yeah, I actually have debugged it pretty thoroughly and use it myself.
> But evidently sendCommand: is only used by client code - not server
> code. :)
>
>
>>-- Jecel
>
>
> regards, Göran
>
>
>
More information about the Squeak-dev
mailing list
|