-
Notifications
You must be signed in to change notification settings - Fork 133
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
IpcOneShotServer::accept is blocking and has no non-blocking version #307
Comments
I'd like a non-blocking accept as well. What I was thinking was:
Return types shouldn't need to change since they already return I'm also happy to open a PR for this if the maintainers will accept the contribution! |
I'd review a PR that added that implementation if you verify that it works as expected! |
try_accept on Unix variants would also need to avoid blocking waiting for a connect request (in libc::accept).
I think there would need to be a change of return types. Consider the Unix behaviour. The current return type:
does not cope with the case where a connect request was available when accept was called. In that case a connection is formed and a receiver can be constructed, but if there is no message available from the receiver, accept needs to return the receiver but no message. The current signature only allows an error to be returned if there is no message available. But that would mean the receiver and the underlying connection will be discarded, rather than returned to allow messages to be received.
|
A non-blocking version is needed to be used in an async context.
Something like
IpcOneShotServer::try_accept()
If you think this is not too difficult for someone, who is very new to this lib, to implement this then I would happily do it.
What return type would make sense?
The text was updated successfully, but these errors were encountered: