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

CA-395554 Improve fairlocking reliability #698

Merged

Conversation

TimSmithCtx
Copy link
Contributor

Under some circumstances (when the listen queue is short enough) a process's blocking connect() to a UNIX-domain stream socket can return success even when the server side has not yet called accept().

To work around this, we have the server portion write a small fixed blob of data to each new connection and require the client to read it before it considers itself to have the lock; merely being connected successfully is no longer sufficient.

MarkSymsCtx
MarkSymsCtx previously approved these changes Jul 23, 2024
Under some circumstances (when the listen queue is short enough) a
process's blocking connect() to a UNIX-domain stream socket can return
success even when the server side has not yet called accept().

To work around this, we have the server portion write a small fixed blob
of data to each new connection and require the client to read it before
it considers itself to have the lock; merely being connected
successfully is no longer sufficient.

Signed-off-by: Tim Smith <tim.smith@cloud.com>
@MarkSymsCtx MarkSymsCtx merged commit ab45ca5 into xapi-project:master Jul 23, 2024
2 checks passed
@TimSmithCtx TimSmithCtx deleted the private/timsmi/CA-395554 branch July 23, 2024 09:59
@rosslagerwall
Copy link
Contributor

Under some circumstances (when the listen queue is short enough) a process's blocking connect() to a UNIX-domain stream socket can return success even when the server side has not yet called accept().

FWIW, connect() on a UDS does not synchronize with accept(). The only time connect() would block is when the listen queue is full. In that case, it will block until the server calls accept() (and pulls a different, already connected, socket from the listen queue).

@TimSmithCtx
Copy link
Contributor Author

Yeah. It would be great if some knowledgeable individual would someday update the unix(7) manual page with this information, particularly since it violates the law of least astonishment. I can't find the behaviour mentioned anywhere.

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

Successfully merging this pull request may close these issues.

4 participants