<div dir="ltr">Hi All,<div><br></div><div> one thing this lock-up suggests is that interrupting should interrupt all processes running at user priority, not just the uiProcess. Does that make sense? It does to me, but would be something I'd control by a preference for testing its effects.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 29, 2016 at 7:23 PM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Levente, Hi All,<div><br></div><div> I'm trying to investigate the socket issues in aio.c but have found a much moire basic issue. With my recent changes to Network that more carefully checked for errors the SocketTest>>testSocketReuse test appears to lock up. In fact, the VM is fine, happily doing what it's being told by Socket>>#sendData:count:</div><div><br></div><div>Socket>>sendData: buffer count: n<div><span style="white-space:pre-wrap">        </span>"Send the amount of data from the given buffer"</div><div><span style="white-space:pre-wrap">        </span>| sent |</div><div><span style="white-space:pre-wrap">        </span>sent := 0.</div><div><span style="white-space:pre-wrap">        </span>[sent < n] whileTrue:[</div><div><span style="white-space:pre-wrap">                </span>sent := sent + (self sendSomeData: buffer startIndex: sent+1 count: (n-sent))].</div><div><br></div><div>The VM keeps trying to send data on a socket that is being reused and gets an error from sendto, answers 0 as the number of bytes sent, as required, but Socket>>#sendData:count: pays no heed and spins hard. Here's the traces:</div><div><br></div><div>The test is SocketTest>>testSocketReuse which spawns two processes, one to send and one to receive data. Here are the processes:</div><div><br></div><div><div>Process 0x48641f8 priority 40</div><div>0xbfec0498 M Socket>sendSomeData:startIndex:count:for: 0x4864d18: a(n) Socket</div><div>0xbfec04c0 M Socket>sendSomeData:startIndex:count: 0x4864d18: a(n) Socket</div><div>0xbfec04ec M Socket>sendData:count: 0x4864d18: a(n) Socket</div><div>0xbfec0520 I [] in SocketTest>testSocketReuse 0x4864dd0: a(n) SocketTest</div><div>0xbfec0540 I [] in BlockClosure>newProcess 0x4864df0: a(n) BlockClosure</div></div><div><br></div><div><div>Process 0x6543178 priority 40</div><div>0xbfec22c8 I [] in Delay>wait 0x4864ea0: a(n) Delay</div><div>0xbfec22f0 I BlockClosure>ifCurtailed: 0x4864eb8: a(n) BlockClosure</div><div>0xbfec2314 I Delay>wait 0x4864ea0: a(n) Delay</div><div>0xbfec2340 I [] in SocketTest>testSocketReuse 0x4864dd0: a(n) SocketTest</div><div>0xbfec2360 M BlockClosure>ensure: 0x4864fa8: a(n) BlockClosure</div><div>0xbfec2390 I SocketTest>testSocketReuse 0x4864dd0: a(n) SocketTest</div></div><div><br></div><div><div>Process 0x4864168 priority 40</div><div>0xbfec3438 I [] in DelayWaitTimeout>wait 0x48652f8: a(n) DelayWaitTimeout</div><div>0xbfec3458 M BlockClosure>ensure: 0x4865378: a(n) BlockClosure</div><div>0xbfec347c I DelayWaitTimeout>wait 0x48652f8: a(n) DelayWaitTimeout</div><div>0xbfec34a0 I Semaphore>waitTimeoutMSecs: 0x48652e0: a(n) Semaphore</div><div>0xbfec34c4 I Socket>waitForDataIfClosed: 0x4865408: a(n) Socket</div><div>0xbfec34f0 I Socket>receiveDataInto:startingAt: 0x4865408: a(n) Socket</div><div>0xbfec3520 I [] in SocketTest>testSocketReuse 0x4864dd0: a(n) SocketTest</div><div>0xbfec3540 I [] in BlockClosure>newProcess 0x48654c0: a(n) BlockClosure</div></div><div><br></div><div>And here's the VM spinning:</div><div><div> 15726 0 sqUnixSocket.c:1128 UDP sendData(11, 16)</div><div> 15726 0 sqUnixSocket.c:1134 UDP send failed 56 Socket is already connected</div><div> 15726 0 sqUnixSocket.c:1128 UDP sendData(11, 16)</div><div> 15726 0 sqUnixSocket.c:1134 UDP send failed 56 Socket is already connected</div><div> 15726 0 sqUnixSocket.c:1128 UDP sendData(11, 16)</div><div> 15726 0 sqUnixSocket.c:1134 UDP send failed 56 Socket is already connected</div></div><div> ...etc...</div><div><br></div><div>Ah!! Of course. Because I have changed the default scheduling semantics in Squeak 5 to make preemption not a yield point, Socket>>#sendData:count: never yields to the other processes. Previously when the Delay process woke up this would implicitly yield the process spinning in Socket>>#sendData:count:.</div><div><br></div><div>So Socket>>#sendData:count: needs to do a yield if no data is sent. However, shouldn't but also check for errors if no data is sent and do something like return an error if it discovers, via Socket>>primSocketError:, that the socket is not happy?</div><div><br></div><div><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><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>