| 28 Jul 2025 |
 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 |
| emily | for a quick test | 01:22:54 |
