| 28 Jul 2025 |
 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 |
| jade_ | or even just start a daemon outside launchd | 01:23:45 |
| jade_ | lets try that | 01:23:47 |
| jade_ |
To change the QoS of a pthread, call pthread_set_qos_class_self_np and pass it the new QoS to apply, as shown in Listing 10-9.
Listing 10-9Changing the QoS of a pthread
pthread_set_qos_class_self_np(QOS_CLASS_BACKGROUND,0);
| 01:28:35 |
| jade_ | yeah so that was simply untrue | 01:28:41 |
| jade_ | you can just change your qos class | 01:28:57 |
| emily | I think tasks and thread priorities are different. maybe. | 01:29:18 |
| emily | might be wrong. | 01:29:29 |
| emily | probably am wrong actually | 01:29:46 |
