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.select returns immediately when waiting for the completion of a non-blocking socket connection #5783

Closed
vicuna opened this issue Oct 10, 2012 · 2 comments

Comments

@vicuna
Copy link

vicuna commented Oct 10, 2012

Original bug ID: 5783
Reporter: vouillon
Status: acknowledged (set by @damiendoligez on 2013-01-03T15:37:06Z)
Resolution: open
Priority: normal
Severity: minor
Version: 4.00.1
Category: platform support (windows, cross-compilation, etc)
Tags: patch
Monitored by: @dbuenzli

Bug description

The C function [select_data_dispatch] checks whether the socket is connected, and systematically consider that the socket is ready when it is not connected.

Thus, when this function is involved, there is no way to wait for the completion of a non-blocking socket connection.

Since OCaml 4, there is a fast path when all file descriptors are sockets. Hence, the bug only occurs when we are also selecting file descriptors of a different kind.

The attached piece of code reproduces the bug.

File attachments

@vicuna
Copy link
Author

vicuna commented Oct 10, 2012

Comment author: vouillon

Maybe the check in [select_data_dispatch] can just be removed? The consequence would be that a non-connected socket will never be reported as ready by [Unix.select] (contrary to what happens under Unix). But this is already the case with the Winsock implementation of [select], which is used when [Unix.select] is called only with sockets...

@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

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

No branches or pull requests

1 participant