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

IpcOneShotServer::accept is blocking and has no non-blocking version #307

Open
pYtoner opened this issue Jan 19, 2023 · 3 comments
Open

Comments

@pYtoner
Copy link

pYtoner commented Jan 19, 2023

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?

@tevoinea
Copy link

I'd like a non-blocking accept as well. What I was thinking was:

  1. Create a try_accept in OsIpcOneShotServer that calls try_recv on the OsIpcReceiver
  2. Create try_accept in IpcOneShotServer that uses the newly created try_accept from step 1

Return types shouldn't need to change since they already return Result.

I'm also happy to open a PR for this if the maintainers will accept the contribution!

@jdm
Copy link
Member

jdm commented Feb 27, 2023

I'd review a PR that added that implementation if you verify that it works as expected!

@glyn
Copy link
Contributor

glyn commented Feb 4, 2025

I'd like a non-blocking accept as well. What I was thinking was:

1. Create a `try_accept` in `OsIpcOneShotServer` that calls `try_recv` on the `OsIpcReceiver`

try_accept on Unix variants would also need to avoid blocking waiting for a connect request (in libc::accept).

2. Create `try_accept` in `IpcOneShotServer` that uses the newly created `try_accept` from step 1

Return types shouldn't need to change since they already return Result.

I think there would need to be a change of return types. Consider the Unix behaviour. The current return type:

Result<(IpcReceiver<T>, T), bincode::Error>

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.

I'm also happy to open a PR for this if the maintainers will accept the contribution!

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

No branches or pull requests

4 participants