[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