<div dir="ltr"><div><a href="http://forum.world.st/Socket-s-readSemaphore-is-losing-signals-with-Cog-on-Linux-td3741174.html">http://forum.world.st/Socket-s-readSemaphore-is-losing-signals-with-Cog-on-Linux-td3741174.html</a><br></div><div><br></div><div>On 8/13/2011 13:42, Levente Uzonyi wrote:</div><div><br></div><div>&gt; Socket&#39;s readSemaphore is losing signals with CogVMs on linux. We </div><div>&gt; found several cases (RFB, PostgreSQL) when processes are stuck in the </div><div>&gt; following method: </div><div>&gt; </div><div>&gt; Socket &gt;&gt; waitForDataIfClosed: closedBlock </div><div>&gt;     &quot;Wait indefinitely for data to arrive.  This method will block until </div><div>&gt;     data is available or the socket is closed.&quot; </div><div>&gt; </div><div>&gt;     [ </div><div>&gt;         (self primSocketReceiveDataAvailable: socketHandle) </div><div>&gt;             ifTrue: [^self]. </div><div>&gt;         self isConnected </div><div>&gt;             ifFalse: [^closedBlock value]. </div><div>&gt;         self readSemaphore wait ] repeat </div><div>&gt; </div><div>&gt; When we inspect the contexts, the process is waiting for the </div><div>&gt; readSemaphore, but evaluating (self primSocketReceiveDataAvailable: </div><div>&gt; socketHandle) yields true. Signaling the readSemaphore makes the </div><div>&gt; process running again. As a workaround we replaced #wait with </div><div>&gt; #waitTimeoutMSecs: and all our problems disappeared. </div><div>&gt; </div><div>&gt; The interpreter VM doesn&#39;t seem to have this bug, so I guess the bug </div><div>&gt; was introduced with the changes of aio.c.</div><div>«  [hide part of quote]</div><div><br></div><div>Oh, interesting. We know this problem fairly well and have always worked </div><div>around by changing the wait in the above to a &quot;waitTimeoutMSecs: 500&quot; </div><div>which turns it into a soft busy loop. It would be interesting to see if </div><div>there&#39;s a bug in Cog which causes this. FWIW, here is the relevant portion: </div><div><br></div><div>             &quot;Soft 500ms busy loop - to protect against AIO probs; </div><div>             occasionally, VM-level AIO fails to trip the semaphore&quot; </div><div>             self readSemaphore waitTimeoutMSecs: 500. </div><div><br></div><div>Cheers, </div><div>   - Andreas </div><div class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div>