posix_spawn + Mach extensions

[willglynn]

I have a project that wants posix_spawn() support. That's a POSIX API (as the name implies) which seems like it's in scope for the libc crate, and adding it seems pretty straightforward.

I specifically want this API for posix_spawnattr_setexceptionports_np(). This is an Apple extension to posix_spawn() which to would therefore also seem in scope for libc, but this is where the slope gets very slippery, and that's why I'm opening an issue instead of going straight to a PR.

See, this call is really just a posix_spawn()ified version of the Mach task_set_exception_ports() function. This means adding it would instantly would instantly drag in a bunch of Mach stuff: types and constants for exception_mask_t, exception_behavior_t, and thread_state_flavor_t, plus mach_port_t itself. It also prompts a choice between:

1. Adding Mach bindings to libc, which is perhaps also in scope considering Mach mach_port_allocate() is literally a syscall just like BSD pipe(), but which is not a small project, or
2. Not adding Mach bindings to libc, which leaves the posix_spawn() family only partially-baked, and in particular means there's no useful way to call posix_spawnattr_setexceptionports_np() without additional bindings outside libc

Both of these options seem terrible. What's worse: the alternative to this unholy union of the Mach + BSD subsystems is to use both subsystems independently, which requires either clobbering the parent process/task's exception ports (which is racy) or passing ports indirectly via NSMachBootstrapServer (which requires Objective-C). posix_spawnattr_setexceptionports_np() really is the best way to spawn a child process with exception ports of the parent's choosing.

So: how do we feel about adding posix_spawn()? What about posix_spawnattr_setexceptionports_np()? What about #include <mach/mach.h>?

[alexcrichton]

Thanks for the report, this does indeed sound thorny!

We've got a few mach type definitions in libc right now (some from mach/mach_time.h), but we definitely don't have anything extensive just yet. The defined scope of this crate is somewhat ambiguous on whether these definitions would go here or not.

My gut would say that if it doesn't require linking more libraries/frameworks we should throw them all into libc, but if they require linking more libraries then they should be external crates.

Is that possible to do?

[willglynn]

My gut would say that if it doesn't require linking more libraries/frameworks we should throw them all into libc, but if they require linking more libraries then they should be external crates.

Is that possible to do?

That sounds good. All the Mach IPC bits are available without extra libraries, so by that standard it all belongs here. That's a bunch of functions plus the associated constants/structs; basically the entirety of <mach/*.h>.

This rule also brings in some library bits. For example, most Mach calls take task as a parameter, and mostly tasks want to affect themselves, so it's extremely common to call mach_task_self() all over the place. There is a syscall that returns the current task, but as an optimization, <mach/mach_init.h> defines:

extern mach_port_t	mach_task_self_;
#define	mach_task_self() mach_task_self_
#define	current_task()	mach_task_self()

I have no idea where that symbol actually lives, but I do know it's populated by dyld very early on process start:

void mach_init() {
	mach_task_self_ = task_self_trap();
	//_task_reply_port = _mach_reply_port();
}

…and it's reset again by dyld before fork() returns. Rather than exposing mach_task_self_ – even though it's technically public – I think it would be better to provide a function mirroring the mach_task_self() macro:

#[inline(always)]
pub fn mach_task_self() -> mach_port_t {
  // C `mach_task_self()` is defined as a macro which returns `mach_task_self_`.
  //
  // Expressed in Rust, that means reading a mutable static, which is unsafe. However,
  // `mach_task_self_` is mutated in exactly two places, neither of which can race here:
  //
  // 1. set by dyld on process start, before user code gets called
  // 2. set by dyld on process fork, in the only running thread before `fork()` returns
  //
  // Therefore, we can read the mutable static here without ourselves being `unsafe`.
  unsafe { mach_task_self_ }
}

This direction makes sense to me so far.

Things will get hairy when it's time to wrap Mach RPC, but "follow C" remains an actionable guideline. Some platform services are provided over Mach RPC with baked-in implementations, while others rely on mig to generate C which you compile and link. This runs into trouble because some platform services require both a baked-in implementation and a generated implementation because of how they chose to navigate the 32 -> 64 bit transition, but that can be pain for a later day. A mach-rpc-sys crate bundling some mig-generated code would work fine, and it could rely on types defined in libc.

So, with Mach in scope, that brings me to another question: should all this go straight into libc?

I would initially reach to put all this into a pub mod mach, perhaps with pub use mach::{stuff} to re-export a handful of things (like mach_timebase_info()). This is different than how libc seems to work everywhere else, and it can all live in a flat namespace, but I think Mach actually does belong in its own world.

Mach has a lot of surface area that's not related to what's currently in libc. Not just functions and structs: there's a whole separate set of primitive types like natural_t because Apple's OS didn't start out related to BSD. There's also a whole separate set of errors: for a situation where a POSIX call might return ENOSPC, some analogous Mach call might return KERN_NO_SPACE, MACH_MSG_IPC_SPACE, MACH_MSG_VM_SPACE, MACH_SEND_NO_BUFFER, or MACH_SEND_TOO_LARGE. The Mach and BSD subsystems are largely perpendicular, and libc at present binds almost exclusively to BSD.

From that description, one might be tempted to conclude that Mach should live in a separate crate, so the counterpoint Mach is available in the standard library, there are cases when you need it, and it does intersect the POSIX world (e.g. posix_spawnattr_setexceptionports_np()). I think a libc::mach module strikes the right balance even though it's unusual.

[alexcrichton]

Yeah having an function for a macro is fine, we've already got a few examples of that in the crate elsewhere.

For now the libc crate is defined as having a flat namespace (like C), so I'd prefer to avoid a mach submodule. I'd also be fine though having an external crate here for awhile and if it's big/popular enough we could move it into libc itself. We could always add functions like posix_spawnattr_setexceptionports_np() with ABI-compatible parameters like usize, right?

[willglynn]

It's possible to use ABI-compatible parameters, but I don't think that avoids the issue of libc needing to know about Mach internals.

For example, mach_port_t typedefs down to a __darwin_natural_t, which the flagrantly arch-specific <i386/_types.h> defines as unsigned int. I don't immediately know if that's true on other platforms, but ensuring that the libc functions which take a mach_port_t are actually ABI compatible will require figuring that out – and if libc has figured out exactly how a mach_port_t is represented, I think it might as well export that type.

As for a flat namespace: that's how it works in C, so that's fine here too. Would you be opposed to having mod mach + pub use mach::*? I think it would be nice to have the Mach APIs/constants in a separate mach.rs, even if everything is exported as libc::*.

[alexcrichton]

Yeah internally we can have whatever structure makes sense.

[gnzlbg]

FYI the mach crate provides (some) of these APIs similar to the winapi crate. I don't know what the long term plan for libc is, but kernel APIs is probably out-of-scope.

I think things would be cleaner if we had independent crates for each platform instead of throwing everything together into a single crate and gluing things with cfgs all over the place.

[gnzlbg]

posix_spawn is available already - for mach APIs, please use the mach crate, which is tested on multiple macosx versions and handle breaking changes to the mach APIs.

[willglynn]

@gnzlbg Neither libc nor mach expose posix_spawnattr_setexceptionports_np().

[gnzlbg]

@willglynn mach would accept a PR implementing it.