| 22 Dec 2025 |
 Ihar Hrachyshka | maybe the original reasoning documented in the comment is no longer applicable, but tap device polling is still an issue. | 15:55:30 |
 Randy Eckenrode | Maybe it only works on newer macOS? | 15:57:29 |
 hexa | it's a bit surprising that nix-darwin does not have a system.autoUpgrade like option 🤔 | 15:58:04 |
| hexa | what I need is to keep the machines in sync with a flake ref | 15:58:43 |
| Randy Eckenrode | The test is whether it supports devices. According to POSIX:
The poll() and ppoll() functions shall support regular files, terminal and pseudo-terminal devices, FIFOs, pipes, and sockets. The behavior of poll() and ppoll() on elements of fds that refer to other types of file is unspecified.
| 16:00:23 |
| Randy Eckenrode | So it doesn’t appear that it’s required to support devices other than (P)TTYs. | 16:01:03 |
| Ihar Hrachyshka | it's a gnu world... | 16:01:17 |
| Randy Eckenrode | If Glib does want to support that, they need emulation. | 16:01:33 |
| Randy Eckenrode | It might be possible to do it with kqueue. That’s how Apple implements poll in XNU. They probably don’t support devices because it’s not required. | 16:02:58 |
| Ihar Hrachyshka | qemu defines fd array as GPollFD poll_fds[1024 * 2]; /* this is probably overkill */ which AFAIU is above the limit on darwin. but then it's probably not something that would be solved by reducing the size of the array since - I assume - qemu has a good reason to listen on so many files (is it because of how nix store is overlayed into these vms?) | 16:04:40 |
| Randy Eckenrode | Does it work if the fd limit is increased? | 16:05:31 |
| Ihar Hrachyshka | maybe I should (somehow) map fds opened by the process to actual files and see what's in the top | 16:05:43 |
| Ihar Hrachyshka | can one increas the limit? thought it's hardcoded in includes and darwin enforces it (which I think is how I get the traceback in Console in the first place) | 16:06:15 |
