Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unix.(set|clear)_close_on_exec changes sockets to blocking mode #5416

vicuna opened this issue Dec 8, 2011 · 1 comment

Unix.(set|clear)_close_on_exec changes sockets to blocking mode #5416

vicuna opened this issue Dec 8, 2011 · 1 comment


Copy link

@vicuna vicuna commented Dec 8, 2011

Original bug ID: 5416
Reporter: ripoche
Status: closed (set by @xavierleroy on 2013-08-31T10:48:40Z)
Resolution: fixed
Priority: normal
Severity: major
Platform: PC
OS: Windows
OS Version: XP SP3 32 bits
Version: 3.12.1
Category: ~DO NOT USE (was: OCaml general)
Related to: #4895

Bug description

Consider the following snippet:

let () =
let server = Unix.socket Unix.PF_INET Unix.SOCK_STREAM 0 in
Unix.set_nonblock server;
Unix.set_close_on_exec server;
Unix.setsockopt server Unix.SO_REUSEADDR true;
Unix.bind server (Unix.ADDR_INET (Unix.inet_addr_any, 1039));
Unix.listen server 10;
output_string stdout "calling Unix.accept on non-blocking socket\n";
flush stdout;
ignore (Unix.accept server)

On Linux 32 bits, the call to accept fails as expected with EAGAIN (EWOULDBLOCK would be fine too).
On WinXP SP3 32 bits, the call to accept blocks.

This issue lies in the Win32 implementation of Unix.(set|clear)_close_on_exec. otherlibs/win32unix/close_on.c uses DuplicateHandle which has the (undocumented) side-effect of resetting sockets to blocking mode.

Note that this trick is from the Win9x era and should probably be replaced by a call to SetHandleInformation.

As a side note, I also noticed the usage of both WinSock and WinSock2 in win32unix. Can I ask what's the point of mixing both ? Do we really need to support Win9X ?

File attachments

Copy link

@vicuna vicuna commented Dec 20, 2011

Comment author: @xavierleroy

Patch applied in SVN trunk, commit 11888.

Re: "what's the point of mixing WinSock and WinSock2?", it's probably historical baggage. I don't know what it would imply to switch entirely to WinSock2 (how many changes? what benefits?). If you have suggestions on this topic, feel free to open another PR with them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant