| 28 Jul 2025 |
 jade_ | okay fyi the build jobs are running as Utility (presumably alongside the daemon) | 01:05:05 |
 emily | maybe the QoS needs to be higher then :) | 01:05:33 |
| emily | though user interactive sounds like it would be interesting | 01:05:56 |
| emily | but worth a try at least… | 01:05:58 |
| jade_ | .. whereas if i run them in a terminal via like, ninja to build a normal lix from source, it's Default | 01:06:07 |
| emily | right | 01:06:17 |
| emily | utility is what it's meant to be | 01:06:36 |
| emily | but it does mean sacrificing perf | 01:06:40 |
| emily | user-initiated might be good to try | 01:06:45 |
| jade_ | i am wondering if the nix daemon itself should be at U-Init or Default | 01:08:12 |
| jade_ | because it is likely to be the one causing the blocking | 01:08:24 |
| jade_ | worried that might possibly starve the UI tho, so it might be at our own peril to up-schedule ourselves | 01:09:43 |
| emily | yeah that's what I mean, just wrap the daemon to get it as user-initiated | 01:12:25 |
| emily | I don't think it's correct but it's worth trying | 01:12:30 |
| 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 |
