<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 16, 2011, at 4:00 49PM, Igor Stasenko wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><br>On 16 August 2011 16:30, Henrik Sperre Johansen<br><<a href="mailto:henrik.s.johansen@veloxit.no">henrik.s.johansen@veloxit.no</a>> wrote:<br><blockquote type="cite"><br></blockquote><blockquote type="cite">On 15.08.2011 23:14, Henrik Sperre Johansen wrote:</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><a href="http://code.google.com/p/pharo/issues/detail?id=4655">http://code.google.com/p/pharo/issues/detail?id=4655</a><br></blockquote><blockquote type="cite"><br></blockquote>Is it already integrated in image(s)?<br></div></blockquote><br><div>As I wrote it a couple of hours ago, I doubt it.</div><div>One half is integrated in 1.4 (raising errors if you try to allocate enough external objects that you'd have to adjust the size), other half in neither 1.3 nor 1.4. (try a GC to free slots before growing beyond current max size). </div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font><blockquote type="cite">Could of course be totally unrelated to the lost signals Levente and others<br></blockquote><blockquote type="cite">are seeing on Unix, but it'd be interesting to hear if that still happened<br></blockquote><blockquote type="cite">with changes in place equivalent to the ones described in issue.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Cheers,<br></blockquote><blockquote type="cite">Henry<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote>Is there another hard limit? Like size of VM table for socket/file handles?</div></blockquote><br></div><div>Huh?</div><div><br></div><div>File handles don't use external objects at all that I'm aware of.</div><div>Didn't even know the VM had a special table for them.</div><div><br></div><div>Sockets use 3 semaphores registered in the externalobjects table each, not cleaned up until Sockets are either explicity destroyed or finalized.</div><div>Xtreams tests used 3 Sockets per test, with no explicit destruction in tearDown, so with 87 tests the default 512 externalObjects table filled up rather quickly with no finalization happening.</div><div><br></div><div>There is no hard limit in Cog per se, except one really shouldn't be adjusting the maxExternalObjects size after startup, as that CAN lead to lost signals. (thoroughly documented in the code)</div><div>max-max size of the table is 64k in current image format (stored in image header), as indicated in the comment in maxExternalObjects: method.</div><div><br></div><div><blockquote type="cite"><div><blockquote type="cite">PS. At least on Windows, independently of the above, if I manually set<br></blockquote><blockquote type="cite">maxExternalObjects to > 4095 (Ie its real size is 8192), I inevitably run<br></blockquote><blockquote type="cite">into<br></blockquote><blockquote type="cite">"CreateThread() failed (8) - Not enough storage is available to process this<br></blockquote><blockquote type="cite">command" errors in the output console if I run the<br></blockquote><blockquote type="cite">XTSocketReadingWritingTest...<br></blockquote></div></blockquote></div><div><div><blockquote type="cite"><br></blockquote></div></div><div>Tried replicating this on OSX, and couldn't do it, so I guess it is Windows-specific?</div><div><br></div><div>Cheers,</div><div>Henry</div></body></html>