epoll-shim https://github.com/jiixyj/epoll-shim implements the Linux timerfd API via threads and POSIX timers. libwayland-server allocates a timerfd per client. sys/timers.h defines TIMER_MAX as 32. As a result.. you can only run 32 Wayland clients! :D And I've started hitting this limit in practice (especially with many WebKit processes). Looks like on Linux, the limit of timers is RLIMIT_SIGPENDING which is 16382 by default: https://stackoverflow.com/questions/11903920/boost-deadline-timer-max-number-of-timers-in-linux Our limit should be raised.
It might make more sense to fix epoll-shim to implement timerfd() API in a more scalable way.
Why are the timer limits so low? Even kqueue timers are limited to a "handful" of timers system wide. Is each non trivial process expected to reimplement the wheel?
Hm, if kqueue is limited to a handful of timers that seems like a problem. Sorry, I'm unfamiliar with the subject area.
(In reply to Conrad Meyer from comment #3) Total number of kqueues per uid is limited by rlimit(2) RLIMIT_KQUEUES with no default limit. Global system number of kqueue timers is limited by sysctl kern.kq_calloutmax with the default value 4096. TIMER_MAX defines the number of elements in the per-process structure, so bumping it arbitrary is not possible without reworking the code. It probably can be increased to e.g. 64, but I doubt that this would be useful.
Obsolete after base af93fea71038?
(In reply to Jan Beich from comment #5) I think so -- the issue in the Subject is still true (TIMER_MAX is still 32), but the user-facing issue has been addressed with the introduction of timerfd to the native syscall interface.