smoker issue on windows - dist/IO/t/io_sock.t out of sequence

[atoomic]

As seen from one of the recent blead smoke https://github.com/Perl/perl5/runs/393799009
This test is failing on smoke-windows-msvc142-amd64

Either we can fix it, either we should skip it on windows and continuous integration.
I would suggest to skip it on CI using one ENV variable.

Test Summary Report
3237
-------------------
3238
../dist/IO/t/io_sock.t                                           (Wstat: 0 Tests: 24 Failed: 0)
3239
  Parse errors: Tests out of sequence.  Found (12) but expected (10)
3240
                Tests out of sequence.  Found (13) but expected (11)
3241
                Tests out of sequence.  Found (14) but expected (12)
3242
                Tests out of sequence.  Found (15) but expected (13)
3243
                Tests out of sequence.  Found (16) but expected (14)
3244

[Leont]

Either we can fix it, either we should skip it on windows and continuous integration.
I would suggest to skip it on CI using one ENV variable.

I don't think skipping it should be the first option. There's no reason to assume this issue only occurs under continuous integration, so users will probably run into it too eventually.

[Leont]

This can only be explained by the client dying between the "ok 9" and the "ok 10".

I don't think we have the error that it does with, but there are only a few possibilities.

[jkahrman]

I've experienced this failure frequently on Windows 7 when built with VS2015 on a Windows 7 x64 host (32 bit or 64 bit Perl). Less so with earlier VS versions. Not easily reproducible when the Win7 built binaries run the test on Windows 10.

The debugging I've done suggests the problem is the not the client dying, but the second/third "$listen->accept" calls failing when the client is closing/destroying it's second/third instance of "$sock". Adding a 1 second sleep after the done/quit for "ok 10/11" (respectively) appears to avoid the failures.

This is in concert with the "some machines seem to suffer from a race condition here" sleeps.

No idea what the underlying problem is, however.

io_sock.patch