On 8/13/2011 13:42, Levente Uzonyi wrote:

> Socket's readSemaphore is losing signals with CogVMs on linux. We��

> found several cases (RFB, PostgreSQL) when processes are stuck in the��

> following method:��

>��

> Socket >> waitForDataIfClosed: closedBlock��

> �� �� "Wait indefinitely for data to arrive.�� This method will block until��

> �� �� data is available or the socket is closed."��

>��

> �� �� [��

> �� �� �� �� (self primSocketReceiveDataAvailable: socketHandle)��

> �� �� �� �� �� �� ifTrue: [^self].��

> �� �� �� �� self isConnected��

> �� �� �� �� �� �� ifFalse: [^closedBlock value].��

> �� �� �� �� self readSemaphore wait ] repeat��

>��

> When we inspect the contexts, the process is waiting for the��

> readSemaphore, but evaluating (self primSocketReceiveDataAvailable:��

> socketHandle) yields true. Signaling the readSemaphore makes the��

> process running again. As a workaround we replaced #wait with��

> #waitTimeoutMSecs: and all our problems disappeared.��

>��

> The interpreter VM doesn't seem to have this bug, so I guess the bug��

> was introduced with the changes of aio.c.

�� ��[hide part of quote]

Oh, interesting. We know this problem fairly well and have always worked��

around by changing the wait in the above to a "waitTimeoutMSecs: 500"��

which turns it into a soft busy loop. It would be interesting to see if��

there's a bug in Cog which causes this. FWIW, here is the relevant portion:��

�� �� �� �� �� �� ��"Soft 500ms busy loop - to protect against AIO probs;��

�� �� �� �� �� �� ��occasionally, VM-level AIO fails to trip the semaphore"��

�� �� �� �� �� �� ��self readSemaphore waitTimeoutMSecs: 500.��

Cheers,��

�� ��- Andreas��