[squeak-dev] Re: Stalling own SqueakSource instance
Klaus D. Witzel
klaus.witzel at cobss.com
Thu May 14 17:24:02 UTC 2009
Hi Tobias,
on Thu, 14 May 2009 17:29:01 +0200, you wrote:
> Hello Klaus,
>
> Am 2009-05-14 um 13:18 schrieb Klaus D. Witzel:
>
> […]
>> The above (re. in contrary to #atEnd, etc) reminded me of this one,
>>
>> - http://bugs.squeak.org/view.php?id=6951
>>
>> perhaps some of the socket states/method comments are out of sync?
>
> This indeed looks like the problem I am experienceing.
> Yet, the code of the respective methods mentioned seems to be
> unchanged. I compared to a recent 3.10 and did not
> notice functional changes.
> Especially, waitForDataIfClosed is still called with to empty
> Blocks.
Yup, this waitForDataFor: timeout ifClosed: [] ifTimeOut: [] looks
strange, since until that point in time no one (especially no one who
sends #receiveData*) might ever have accessed the socket other than for
status *queries*.
If you can *still* reproduce your original problem then I'd suggest to
#waitForData* only if zero bytes where seen, that is, do the following
small change:
1) let #receiveDataTimeout:into:startingAt: first read and memorize num
bytes
2) then, if numbytes was 0, do #waitForData* and redo #receiveData*
I know that it is complex to provoke the above, just for testing, but you
seem to have a problem at hand which could get us one step closer to a
possible solution.
Between 1) and 2) a status change may be reported by the VM/plugin to the
socket, which otherwise might not have been the case (in the way mentioned
above).
If I was unclear then please ask.
> Is some advance concerning this bug to be expected in the near
> future?
Dunno, there was some discussion but googleing didn't find any patch or
suggestion.
/Klaus
> -Tobias Pape
More information about the Squeak-dev
mailing list
|