cqueues

ution: it's an incomplete refactor of a similar shim I used in some non-open source code. The original code is even simpler and has seen extensive use. The refactored shim should work but is untested.) AIX is really the only mainstream Unix lacking an API w/ equivalent semantics. AIX has a better-than-poll interface, but it doesn't work anything like the others. Notably, epoll, kqueue, and Solaris ports control descriptors are all pollable in their own right, permitting you to nest different [readiness polling-based] event loop frameworks.

doesn't mean we have to discard threads. That's throwing the baby out with the bath water. Self-promotion: I had stumbled on the idea of "nurseries", independently and many years before the above were published. See https://github.com/wahern/cqueues It's nominally a non-blocking "threading" API for Lua. (In Lua coroutines are also called threads.) But note the plural, continuation queues. It's trivial to instantiate a queue, which is similar to a nursery. This was by design. Many cqueues projects naturally end up with a tree of thread controllers/schedulers. It doesn't work on Windows (yet) because it relies on the fact that kqueue, epoll, and Solaris Ports descriptors can be recursively polled. [1] Serial != synchronous/blocking.

ly sized to 1023! And like Solaris, open path maximum seems to be 1023 (as judged by trying ls -l /path/to/socket). Thanks to Polar Home, polarhome.com, for the free AIX shell account. Note that all the above lengths are exclusive of NUL, and the passed socklen_t argument did not include a NUL terminator. For posterity: on all these systems you can still create sockets with long paths, you just have to chdir or use bindat/connectat if available. My test code confirmed as much. And AFAICT getsockname/getpeername will only return the .sun_path path (if anything) used to bind or connect, but that's a more complex topic (see https://github.com/wahern/cqueues/blob/e3af1f63/PORTING.md#g...)

ssues/56 - https://github.com/ziglang/zig/issues/2425

ng pselect expecting there won't be a race. You can see the race with this code, which on 10.10.5 still fails. What should happen is that it exits immediately with OK. What actually happens on macOS is that its pselect wrapper unblocks the signal, which is immediately delivered. But by then we've already checked that interrupted was still 0. It then calls select, which will timeout because it won't be interrupted--the signal was already delivered. On every other platform implementing pselect (which all do it correctly), pselect will always return EINTR because the signal unmasking and delivery happens in the kernel _after_ entering select. #include <errno.h> #include <signal.h> #include <stdio.h> #include <sys/select.h> #include <unistd.h> #include <err.h> static int interrupted; static void interrupt(int signo) { interrupted = signo; } int main(void) { struct timespec timeout = { 3, 0 }; sigset_t empty, block; int n; sigemptyset(&empty); sigemptyset(&block); sigaddset(&block, SIGHUP); sigprocmask(SIG_BLOCK, &block, NULL); signal(SIGHUP, &interrupt); raise(SIGHUP); while (!interrupted) { /* * If pselect does not atomically unblock signals, pselect * will never be interrupted and we'll lose the signal until * something else wakes us up AND we remember to check even * though we never saw EINTR. */ n = pselect(0, NULL, NULL, NULL, &timeout, &empty); if (n == -1 && errno != EINTR) { err(1, "pselect"); } else if (n == 0) { errx(1, "timed out"); } } if (interrupted != SIGHUP) errx(1, "wrong signal (got %d, expected %d)", interrupted, SIGHUP); puts("OK"); return 0; } [1] FWIW, here's a correct implementation of pselect for macOS using kqueue. (https://github.com/wahern/cqueues/blob/snap-20160812/src/cqu...) The only caveat is that creating a kqueue descriptor might fail, and you don't normally expect pselect to fail with EMFILE or ENFILE; it might even make it non-compliant. Except for that caveat, it's a compliant implementation of pselect AFAICT.