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

Support Mach ports on macOS and iOS #1500

Closed
turbocool3r opened this issue Jun 15, 2021 · 5 comments
Closed

Support Mach ports on macOS and iOS #1500

turbocool3r opened this issue Jun 15, 2021 · 5 comments

Comments

@turbocool3r
Copy link

Darwin platforms (macOS, iOS, etc.) provide a platform-specific IPC mechanism called Mach ports. These are different from sockets in that they pass specially structured messages which may contain special entities like kernel object handles (which are themselves represented by Mach ports). Most kernel APIs as well as the XPC framework are implemented using Mach ports on these platforms, this includes everything related to USB. Also interaction with system services on Darwin is mostly done either using XPC or raw Mach ports. The interface for asynchronous kernel APIs is mostly documented and basically involves polling a "wake" Mach port (aka IONotificationPort) for messages. There is also EVFILT_MACHPORT which allows to add Mach ports support to existing kqueue code more easily.

I believe this will create a lot of new uses for tokio on these platforms.

@Thomasdezeeuw
Copy link
Collaborator

I'm afraid I can't really judge the situation here. I'm not too familiar with Mach ports so it's hard for me to say whether it's a good fit for Mio from this description. Can you propose API you like to see, preferably with underlying system call name, maybe examples (in another language) etc.

@turbocool3r
Copy link
Author

Mach messages are sent/received using the mach_msg trap (one may send and receive a message in the same call). I guess the appropriate API would be somewhat similar to the way user interacts with UDP sockets except that there should be an abstraction for a Mach message that takes its various quirks into account. Here is an example from the chromium source that uses the EVFILT_MACHPORT kqueue filter to watch for events https://chromium.googlesource.com/chromium/src/+/refs/heads/main/base/message_loop/message_pump_kqueue.cc. Also see http://web.mit.edu/darwin/src/modules/xnu/osfmk/man/mach_msg.html.

@Thomasdezeeuw
Copy link
Collaborator

After a quick look I think Mio would need to provide a way to register Mach ports using EVFILT_MACHPORT. Then the actual usage of the Mach port can be in an external crate. Similar to how we support AIO using Interest::AIO and mio-aio. How does that sound as a minimal interface?

@turbocool3r
Copy link
Author

That actually sounds awesome! Seems like the right thing to do considering that Mach ports are a very platform-specific feature.

@Thomasdezeeuw
Copy link
Collaborator

Closing due to inactivity. @turbocool3r if this is something you still want let us know.

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

2 participants