[Vm-dev] Socket's readSemaphore is losing signals with Cog on
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
>>> 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.
> 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.
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.
PS. At least on Windows, independently of the above, if I manually set
maxExternalObjects to > 4095 (Ie its real size is 8192), I inevitably
"CreateThread() failed (8) - Not enough storage is available to process
this command" errors in the output console if I run the
More information about the Vm-dev