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

Igor Stasenko siguctua at gmail.com
Tue Aug 16 14:00:49 UTC 2011


On 16 August 2011 16:30, Henrik Sperre Johansen
<henrik.s.johansen at veloxit.no> wrote:
>
> 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
>
Is it already integrated in image(s)?

> 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...
>
>
Is there another hard limit? Like  size of VM table for socket/file handles?


-- 
Best regards,
Igor Stasenko AKA sig.


More information about the Vm-dev mailing list