[Vm-dev] Socket's readSemaphore is losing signals with Cog on Linux

Henrik Sperre Johansen henrik.s.johansen at veloxit.no
Tue Aug 16 13:30:22 UTC 2011


On 15.08.2011 23:14, Henrik Sperre Johansen wrote:
>
> On 15.08.2011 19:14, Colin Putney wrote:
>>
>> On Sun, Aug 14, 2011 at 12:44 PM, Levente Uzonyi<leves at elte.hu>  wrote:
>>
>>> So I'm pretty sure this bug is Cog specific. Reproducing it seems to be
>>> pretty hard, so a code review (with sufficient knowledge :)) is more 
>>> likely
>>> to help solving this issue.
>> FWIW, I can reproduce it fairly easily using the Xtreams test suite.
>> Running XTSocketReadingWritingTest almost always has several tests
>> time out because of it.
>>
>> Colin
> FWIW, I ran the XTSocketReadingWritingTest often enough to see errors 
> in the results, and interrupted it while it looked to be hanging (this 
> in Windows).
> In latest Pharo images, I got the "'Not enough space for external 
> objects, set a larger size at startup!'" error message I added for 
> trying to adjust ExternalSemaphoreTable size at runtime.
> If default behaviour in your image is to just silently increase 
> size/not increase it at all, that may explain the lost signals.
>
> Cheers,
> Henry
http://code.google.com/p/pharo/issues/detail?id=4655

With this, I can run Xtreams tests as much as I want without timeouts. 
(On Windows at least)
There are still occasional failures, afaict they're due to threading 
bugs in the tests and not signal losses though.

Could of course be totally unrelated to the lost signals Levente and 
others are seeing on Unix, but it'd be interesting to hear if that still 
happened with changes in place equivalent to the ones described in issue.

Cheers,
Henry

PS. At least on Windows, independently of the above, if I manually set 
maxExternalObjects to > 4095 (Ie its real size is 8192), I inevitably 
run into
"CreateThread() failed (8) - Not enough storage is available to process 
this command" errors in the output console if I run the 
XTSocketReadingWritingTest...



More information about the Vm-dev mailing list