| 28 Jul 2025 |
 emily | the actual correct thing to do is to make sure IPC happens via Mach ports, which will automatically "donate" the QoS class of the client to processes it talks to while they service its request | 01:12:53 |
| emily | so a terminal-initiated build would raise the spawned builds to default but one from a background service wouldn't | 01:13:10 |
 jade_ | i would put "correct" in quotes tho | 01:13:13 |
| emily | I think there is no inherent obstacle to doing this with capnproto | 01:13:18 |
| jade_ | since that is very not portable | 01:13:20 |
| emily | it's pretty portable if you have a transport-agnostic RPC layer already | 01:13:32 |
| jade_ | and i worry that it might make debugging annoying | 01:13:33 |
| emily | they're pretty comparable to Unix sockets, can even pass FDs | 01:13:39 |
| jade_ | * and i worry that it might make debugging/running one-off daemons annoying | 01:13:43 |
| emily | but of course it does require everything to be using capnproto already | 01:13:51 |
| emily | (I assume Unix socket and over-the-network transports will need to coexist anyway for remote builds, so another local transport doesn't seem like too much additional complexity) | 01:14:19 |
| jade_ | are mach ports api compatible by presenting fds? | 01:14:22 |
| jade_ | * are mach ports api compatible by presenting an fd based interface? | 01:15:12 |
| emily | they're not stream sockets, no | 01:15:21 |
| emily | they would need implementing as a backend in capnproto | 01:15:39 |
| jade_ | ah. that's kiiiinda annoying in that it's more darwin only code, but if we can keep it contained it might be okay | 01:16:34 |
| emily | ideally it's Darwin code upstream in capnproto | 01:16:46 |
| emily | (and then some brief glue around the server/client boundaries in Lix to select the right one based on platform, but presumably this already needs abstracting for local vs. remote RPC) | 01:17:45 |
| emily | but that's why quickly wrapping the daemon to try default/user-initiated QoS may produce more immediately useful data :) | 01:18:22 |
| jade_ | yes indeed. some inspection of the apis in absence of docs for non-objc-extended-universe apps is required i think. | 01:19:07 |
| emily | which APIs are you talking about? all of this stuff is lower level than Objective-C AFAIK | 01:20:11 |
| emily | Mach ports are very low-level; XPC is the higher-level IPC system built on top of them but I think Mach ports would likely be the right integration layer for Cap'n Proto. they're just very raw C APis to talk directly to the poor microkernel screaming endlessly at the heart of XNU | 01:21:39 |
| emily | QoS stuff is, uh, "there's an undocumented posix_spawn helper" | 01:21:52 |
 raitobezarius | don't forget to document these ideas in the issue trcaker | 01:22:05 |
| jade_ | bazel post suggests that you can't set the policy except via posix_spawn so you can't do it to existing processes or if you are fork/exec. I think theyre mistaken on that. | 01:22:08 |
| emily | yes I think that's probably not true | 01:22:21 |
| emily | but not totally sure | 01:22:35 |
| jade_ | I have found a setiopolicy_np but idk what it does | 01:22:41 |
| emily | I mean | 01:22:43 |
| emily | I'm pretty sure you can just taskpolicy around the daemon invocation in the launchd service | 01:22:51 |
