Comment author: @xavierleroy

I checked the Win32 implementation of send and recv, and the master lock is properly released, allowing both system calls to run in parallel. So, I suspect the mutual exclusion occurs in the Win32/Winsock system calls themselves. Concerning your comparison with C, did you keep in mind that OCaml creates sockets in blocking mode, which may not be the case in your C program? That could at least explain the difference.

Comment author: @dra27

You're correct - I hadn't seen the setsockopt calls in select.c and accept.c. Attached is my hacked up C equivalent code (compiled with gcc -mno-cygwin -o foo.exe foo.c -lws2_32)

According to MSDN (http://msdn.microsoft.com/en-us/library/windows/desktop/ms740532(v=vs.85).aspx), SO_OPENTYPE is deprecated and WSASocket should be used instead with WSA_FLAG_OVERLAPPED not given in dwFlags. If you alter the call to WSASocket in my example to have 0 for the last parameter then the C code exhibits the same problem as the OCaml code - so it's Winsock, not OCaml specifically.

But - why is this Microsoft specific socket option being set in the first place? As far as I can see, all you're doing is creating sockets which can't use overlapping operations (which aren't used anyway) - can't the call simply be removed? Note that overlapped I/O and blocking/non-blocking in Microsoft parlance are unrelated concepts: see first para of http://msdn.microsoft.com/en-us/library/windows/desktop/ms740087(v=VS.85).aspx - ioctlsocket still controls blocking or non-blocking settings.

Comment author: @xavierleroy

The "SO_OPENTYPE = SO_SYNCHRONOUS_NONALERT" hack probably goes back to the early days of the win32unix library, i.e. Windows NT 4 / Windows 98 (or maybe even 3.5 / 95). At that time, I think it was necessary so that sockets would be created in blocking mode. But many things have changed since then. We'd gladly consider a patch to modernize this aspect of win32unix (and maybe others too), provided you give it some testing on your applications first.

Comment author: @dra27

I'm just putting a Windows 7 virtual PC together for some serious testing ... I agree that I think all these bugs are related to this. Will get back to you later today!

Comment author: @dra27

OK - I've tested two possible ways of fixing it.

The first is simply to remove lines 31-41 & 49 in otherlibs/win32unix/select.c and 29, 34-42 & 48-52 in otherlibs/win32unix/accept.c

The second is to invert the logic of the getsockopt block instead - i.e. ensure that SO_OPENTYPE is zero rather than non-zero before calling socket (or accept)

I don't know which you'd prefer - the first option (deleting the problem code) was my instinct; the second one guards against another linked in C library messing around with Winsock options (I don't know whether this is something you'd want to care about in general or not, though).

Happy to provide a patch for either, if necessary.

Note that neither option fixes PR 5327, surprisingly.

Comment author: @dra27

Patches against trunk for both options attached...

Comment author: @xavierleroy

Thanks for the patches. For the sake of simplicity, I go with the "delete" patch, which is now applied in SVN trunk, commit 11966.

Comment author: @xavierleroy

Because we lack time to fix #5578 in time for release 4.00, I reverted the patch on branch version/4.00 but left it on trunk.

Comment author: @damiendoligez

Note that this was inadvertently reverted also in trunk when merging the 4.00.1->4.00.2+dev changes.

re-patched in trunk/4.01 (rev 13743) but then we still need to address #5578

Comment author: @alainfrisch

Re-opening since the fix for #5578 required to undo the fix for #5325.

Comment author: @xavierleroy

See proposed fix in #331

Comment author: @alainfrisch

I checked that the example works fine with trunk and the MSVC 32-bit port.

Comment author: @xavierleroy

Fix committed to trunk, will be in 4.03.

Comment author: enrico

That is awesome! Thanks.