Jade Lovelace
69ba3c92db
This was an absolute nightmare to diagnose. It turns out there's a kernel bug: poll with events = POLLHUP will receive an event for NOT POLLHUP internally in the kernel, delete their event subscription, and then not receive events for any HUP later. lol! lmao!! We choose to use plain old EVFILT_READ because the watched fd can be either a socket or a pipe and it's preferable to eat some spurious wakeups than have separate paths for those. The alternative is using EVFILT_SOCK, a private API that's existed for years and which netty uses for its sockets, but that doesn't work on pipes. Fixes: https://git.lix.systems/lix-project/lix/issues/729 Change-Id: If72b5d7a39f00320a9acccdbe81121cdb1a04c45
717 B
717 B
synopsis, cls, issues, category, credits
| synopsis | cls | issues | category | credits | |||
|---|---|---|---|---|---|---|---|
| Ctrl-C works correctly on macOS again |
|
|
Fixes |
|
Due to a kernel bug in macOS's poll(2) implementation where it would forget about event subscriptions, our detection of closed connections in the Lix daemon didn't work and left around lingering daemon processes.
We have rewritten that thread to use kqueue(2), which is what the poll(2) implementation uses internally in the macOS kernel, so now Ctrl-C on clients will reliably terminate daemons once more.
This FD close monitoring has had the highest Apple bug ID references per line of code anywhere in the project, and hopefully not using poll anymore will stop us hitting bugs in poll.