| 22 Dec 2025 |
 Randy Eckenrode | Or malloc it based on the size of the incoming set. | 17:49:12 |
| Randy Eckenrode | Glib supports using cleanup functions to make that less messy. | 17:49:27 |
| Randy Eckenrode | Though if it’s a mask for all fds, you don’t really know the needed size. | 17:50:00 |
| Randy Eckenrode | https://man.freebsd.org/cgi/man.cgi?select | 17:52:21 |
| Randy Eckenrode | Apple mentioned FreeBSD being unlimited. I agree we should probably increase the amount of memory it’s using (either by defining FD_SETSIZE or some other way). | 17:53:19 |
| Randy Eckenrode | Looks like (unsurprisingly) FreeBSD has a similar implementation.
https://github.com/freebsd/freebsd-src/blob/f51e9d0e0988df58c94db586ab5c8b5fd091c004/sys/sys/select.h#L65
| 17:55:17 |
| Randy Eckenrode | I guess FreeBSD doesn’t enforce the limit if you define it to something non-default. | 17:55:46 |
 Ihar Hrachyshka | so darwin just broke the api to pass posix | 17:56:22 |
| Ihar Hrachyshka | well, broke -> adjusted to standard | 17:56:33 |
 hexa | Randy Eckenrode, emily any reason I should not update the darwin buildfarm to tahoe? | 21:45:40 |
|  -chi left the room. | 21:48:15 |
| Randy Eckenrode | Not that I can think of. It hasn’t broken Nix or Nixpkgs like updates have in the past. | 21:48:50 |
 Alyssa Ross | poll usability flip-flopping every macOS release is a sort of famous example of macOS POSIX-noncompliance: https://daniel.haxx.se/blog/2016/10/11/poll-on-mac-10-12-is-broken/ | 21:49:59 |
| Alyssa Ross | * poll usability flip-flopping between macOS releases is a sort of famous example of macOS POSIX-noncompliance: https://daniel.haxx.se/blog/2016/10/11/poll-on-mac-10-12-is-broken/ | 21:50:19 |
| Alyssa Ross | it might well presently work, but the track record is not confidence-inspiring | 21:50:48 |
| Alyssa Ross | and since you couldn't tell at build time whether the built program would end up being run on a macOS with broken poll, hardcoding not to use it on macOS was the only sensible solution | 21:52:12 |
| Alyssa Ross | (assuming the complexity of detecting it at runtime isn't worth it) | 21:52:55 |
| Alyssa Ross | * | 21:53:07 |
| Ihar Hrachyshka | it won | 21:55:45 |
| Ihar Hrachyshka | * it won't help us anyway since it doesn't support device files | 21:55:58 |
| Randy Eckenrode | The later poll change appears to have been a bug. | 22:03:10 |
| Randy Eckenrode | Not sure how they passed with the bug though. 🤷🏻♂️ | 22:03:44 |
 Winter | the opposite of nobody fwiw ;) | 22:58:35 |
| Ihar Hrachyshka | checked which fds are opened by qemu. basically, for every process inside the vm, each .so (or .dll for dotnet apps) is in the list for all services. since I'm using the VMs to test changes to my biefy VMs running lots of services (like jellyfin or *arr stack), the list gets exhausted. It's probably a function of these VMs using nix store overlay and not directly copying packages into the VM image. (otherwise I'd expect qemu opening just the image file). | 23:54:21 |
| Ihar Hrachyshka | one probably wouldn't even need to run a lot of services at the same time - just start and stop different processes serially and you should be able to hit the limit eventually. because with each nix store open (even if momentary), a new fd number is allocated sequentially. eventually it will reach 1024. AFAIU the limit is on the fd number, not on the length of the array. | 23:57:29 |
| 23 Dec 2025 |
| Ihar Hrachyshka | this seems to work (setting both macros): https://github.com/booxter/nixpkgs/commit/43a6fcf215ec455b41379d6d68e2a93aff626f26
will now check if setting just -D_DARWIN_UNLIMITED_SELECT is enough. | 00:31:06 |
| Ihar Hrachyshka | (the GPollFD poll_fds[1024 * 2]; /* this is probably overkill */ comment in qemu seems to assume that they don't expect anyone to map the whole distro into VM :D) | 00:31:38 |
| Ihar Hrachyshka | * (the GPollFD poll_fds[1024 * 2]; /* this is probably overkill */ comment in qemu seems to suggest that they don't expect anyone to map the whole distro into VM :D) | 00:33:31 |
| Ihar Hrachyshka | * checked which fds are opened by qemu. basically, for every process inside the vm, each .so (or .dll for dotnet apps) is in the list for all services. since I'm using the VMs to test changes to my beafy VMs running lots of services (like jellyfin or *arr stack), the list gets exhausted. It's probably a function of these VMs using nix store overlay and not directly copying packages into the VM image. (otherwise I'd expect qemu opening just the image file). | 00:33:59 |
| Ihar Hrachyshka |
one probably wouldn't even need to run a lot of services at the same time - just start and stop different processes serially
Actually this is not true since fds are reused. one has to hold on to the fd (e.g. with a process running inside the VM).
| 00:56:00 |
