2 ms·
> removes the risk of doing too much in the signal handler Not a concern here, since the signal handler is restricted from running at any time other than durin
by kentonv 4y ago
> removes the risk of doing too much in the signal handler
Not a concern here, since the signal handler is restricted from running at any time other than during epoll_pwait(), so the usual async-signal-safety concerns don't apply. In fact I think the code ends up cleaner than with signalfd, and there are fewer syscalls (no separate read() needed).
- tlsalmin 4y agoThis is getting into taste territory but sure just getting the signal in epoll_pwait removes the need for FD reading. But introduces the need for the thread local global context and the need to handle EINTR from epoll right? I can see how checking if signals were called in the EINTR-branch is nice though. Anyway nice to know the p-version use case.