Suggestion: RawMachPort type on macOS and iOS

libs
1

Currently there are RawFd in std::os:unix::io on unix-like systems and RawHandle and RawSocket on windows and their corresponding traits, but on macOS and iOS there are no similar types/traits for Mach port handles (names). Since Mach ports are extensively used for communication with kernel and system services on these systems (most importantly for asynchronous kernel method calls) I believe supporting them on these platforms is important.

I suggest providing an abstraction for a raw Mach port handle in one central crate to prevent developers who want to provide some kind of functionality related to Mach ports from each providing their own type. This may be a simple pub type RawMachPort = libc::c_int and a set of traits (AsRawMachPort, IntoRawMachPort and FromRawMachPort).

An example where this may be used: IOKit object handles are effectively Mach port handles, however the IOKit framework abstracts this behind a stable C API. Someone developing IOKit bindings (hi!) may want to provide the ability to extract the handle without relying on a specific crate that provides Mach interface bindings.

Questions:

  1. Should it be in the standard library or a separate crate? Seems like Mach ports, unlike Windows handles, sockets and file descriptors aren't used in the standard library currently. On the other hand there is now a type in the standard library for raw Windows kernel object handles, however on macOS/iOS there is none.
  2. Should there be any other related types/traits?
2

At least initially, I think this should live in a third-party crate; it can always be moved into the standard library later.

Also, take a look at the work being done in the posish project, which is experimenting with safer types for things like RawFd. I think for a new type like MachPort, we should take that approach from the start.

4 Likes
3

Thanks! Unfortunately the posish approach won't work well with Mach port handles since their ownership model is more complicated, but the safer type direction definitely seems like the right way to go.

4

I wasn't suggesting that an identical model would necessarily work; I'm just suggesting that we should look for a safe model that fits the semantics of Mach ports.

5

If it makes sense for this to be a third-party crate, I'm interested in learning more about internals-centric issues and I would be up for contributing to this @josh.

6

I do think it makes sense to start out as a third-party crate.

7

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.