[Vm-dev] I would be extremely grateful for a reproducible case for
the following Socket issue
Eliot Miranda
eliot.miranda at gmail.com
Wed Mar 23 18:26:44 UTC 2016
http://forum.world.st/Socket-s-readSemaphore-is-losing-signals-with-Cog-on-Linux-td3741174.html
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
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160323/34dee189/attachment.htm
More information about the Vm-dev
mailing list