Asynchronous execution is: do this operation, then wait until finish event occurs.
They are opposites.
The client decides when to look at the ring buffer
The whole point of async is to find a compromise between context switch cost and event buffering and the latency resulting from the latter. It is not about "running a function".
An intern of mine wrote a whole tcp-checkpoint-(pause-ingress-and-egress-and-the-socket-save-all-state-unpause-everything)-and-send-full-state-on-other-socket (which was a dozen or so ops - netlink writes, ioctls, set/getsockopt, read/write calls...) in a chain - all in one command-queue-write IIRC.
Performance was as good as an ad-hoc kernel module, without any ebpf. We just had one kernel patch to handle some unhandled syscall (getsockopt ? Setsockopt ? Ioctl?) (that we sadly didn't upstream... 2 years ago) and we were done. Really a great system for batching syscalls.
It made me wish for a form of DAG for error-handling or for parallel operations in chains...
What is a signal handler?
It's not always either/or, though. From the perspective of userspace APIs it's usually one or the other, but further down the stack one model might be implemented in terms of the other, sometimes with multiple transitions between the two, especially around software/hardware boundaries. Basically, it's turtles all the way down.
Similarly, the debates regarding cancellation, stack management, etc, still persist; the fundamental dilemmas haven't changed.
Systems programmers were told that the best signal handler function was one that set a flag, a volatile int, and then exited immediately without doing or touching anything else.
Sort of defeats the purpose of the elaborate signal-handler-callback-pointer-to-function system we had in place, but them's the breaks.
Like other people here wrote nowadays one can push some processing into kernel context, but that sort of defeats the purpose of kernel/userland border. One can just write a kmod and be done with it then (and lose isolation).
PunchyHamster•4mo ago
It's not an event system at all! It's an event system!
The type of events being subset of all possible events in system does not make it not events system. Nor it being essentially a queue
ciconia•4mo ago
jcelerier•4mo ago
first time in my life I hear people calling this an event system. For me it's always been any architecture centered around asynchronous message queues.
hxtk•4mo ago
Sharlin•4mo ago