On Fri, 2017-06-09 at 14:39 -0500, Eric Blake wrote: > On 06/09/2017 02:19 PM, Knut Omang wrote: > > This series contains: > > * a unit test that exposes a race condition which causes QEMU to fail > > to find a port even when there is plenty of available ports. > > * a refactor of the qemu-sockets inet_listen_saddr() function > > to better handle this situation. > > > > Thanks, > > Knut > > > > Knut Omang (2): > > Add test-listen - a stress test for QEMU socket listen > > socket: Handle race condition between binds to the same port > > > > I'd reorder the series, to put the fix first and the test second, rather > than the (crippled) test first.
Are there good reasons not to have the test first? (as long as it does not break the build). IMHO the logical test driven approach is to have the test first to highlight/reproduce the issue. > Someone that wants to prove that the > test works can easily apply the patches out of order. Yes, but in my view that's both less logical and less convenient? Thanks, Knut
