4 ms·
I wrote many of my own programs on elf/linux: I do epoll as much as I can. The only troubling thingy is the lack of classification of signals, those who are sy
by sylware 4y ago
I wrote many of my own programs on elf/linux: I do epoll as much as I can.
The only troubling thingy is the lack of classification of signals, those who are synchronous by nature and the other ones. For instance, in a monothreaded application, segfault won't be delivered via epoll...
At the same time, it is still important to keep the asynchronous API for signals that for lower latency, but then, only the realtime behaviour should be kept since this is really where latency does matter.
- cryptonector 4y agoSynchronous signals can't possibly be delivered via an asynchronous mechanism like epoll. Well, I suppose they could, but only if the thread that tripped the synchronous signal is put to sleep until some other thread runs a handler for that signal, but this requires APIs that (to my knowledge, except... ptrace) don't exist, and there's no need for them. If you can handle a SIGBUS or SIGSEGV, you don't need to handle them asynchronously, but on the other hand if you can't handle them, then the process will die, so there's just no need to handle these asynchronously.
- sylware 4y agoExactly what I said: this needs clarification. Maybe adding explicitely the 2 flavors of signals.
- cryptonector 4y agoNo, it doesn't need clarification. Synchronous signals are always always synchronous, therefore it's obvious that they cannot be handled asynchronously with <fill-in-the-blank-async-system>. It's really clear. And if you stop to think about why synchronous signals are synchronous, it's even more clear.
- sylware 4y agoI disagree, I think it is not clear enough in POSIX.