What's the difference between event-driven and asynchronous? Between epoll and AIO?

Question

Event-driven and asynchronous are often used as synonyms. Are there any differences between the two?

Also, what is the difference between epoll and aio? How do they fit together?

Lastly, I've read many times that AIO in Linux is horribly broken. How exactly is it broken?

Thanks.

Swope

Imagine threads which allow asynchronous behavior independent upon using an event-driven architecture. Event-driven architectures often allow the program to "live within one container" (e.g. one thread, one process, etc. which can keep some tasks simple) but don't preclude other "across container" asynchronous techniques. – Crossly

Answer 1

Events is one of the paradigms to achieve asynchronous execution. But not all asynchronous systems use events. That is about semantic meaning of these two - one is super-entity of another.

epoll and aio use different metaphors:

epoll is a blocking operation (epoll_wait()) - you block the thread until some event happens and then you dispatch the event to different procedures/functions/branches in your code.

In AIO, you pass the address of your callback function (completion routine) to the system and the system calls your function when something happens.

Problem with AIO is that your callback function code runs on the system thread and so on top of the system stack. A few problems with that as you can imagine.

Santiago

Answer 2

They are completely different things.

The events-driven paradigm means that an object called an "event" is sent to the program whenever something happens, without that "something" having to be polled in regular intervals to discover whether it has happened. That "event" may be trapped by the program to perform some actions (i.e. a "handler") -- either synchronous or asynchronous.

Therefore, handling of events can either be synchronous or asynchronous. JavaScript, for example, uses a synchronous eventing system.

Asynchronous means that actions can happen independent of the current "main" execution stream. Mind you, it does NOT mean "parallel", or "different thread". An "asynchronous" action may actually run on the main thread, blocking the "main" execution stream in the meantime. So don't confuse "asynchronous" with "multi-threading".

You may say that, technically speaking, an asynchronous operation automatically assumes eventing -- at least "completed", "faulted" or "aborted/cancelled" events (one or more of these) are sent to the instigator of the operation (or the underlying O/S itself) to signal that the operation has ceased. Thus, async is always event-driven, but not the other way round.

Mitzimitzie

You say- "Mind you, it does NOT mean "parallel", or "different thread"." Can you explain more with an example. If the event is handled within the main thread, how is it independent of the current main execution stream? – Quaternary

Certain software systems implement co-routines, for example, that enables switching between streams of execution within the same thread. Yet other systems may "preempt" the current operation upon receipt of an event, run the handler, and then resume execution of the original stream, all inside the same thread -- think interrupts. Some systems do not support any of these, and require the events to be "stored away", waiting for the main thread to finish its current operation and then explicitly "fetch" it -- think JavaScript and Windows message loop. – Mitzimitzie

Hi Stephen, I think linux singal handler is a instance of co-routines in this scenario. Is it right? – Liselisetta

Answer 3

Event driven is a single thread where events are registered for a certain scenario. When that scenario is faced, the events are fired. However even at that time each of the events are fired in a sequential manner. There is nothing Asynchronous about it. Node.js (webserver) uses events to deal with multiple requests.

Asynchronous is basically multitasking. It can spawn off multiple threads or processes to execute a certain function. It's totally different from event driven in the sense that each thread is independent and hardly interact with the main thread in an easy responsive manner. Apache (webserver) uses multiple threads to deal with incoming requests.

Viveca

Answer 4

Lastly, I've read many times that AIO in Linux is horribly broken. How exactly is it broken?

AIO as done via KAIO/libaio/io_submit comes with a lot of caveats and is tricky to use well if you want it to behave rather than silently blocking (e.g. only works on certain types of fd, when using files/block devices only actually works for direct I/O but those are the tip of the iceberg). It did eventually gain the ability to indicate file descriptor readiness with the 4.19 kernel) which is useful for programs using sockets.

POSIX AIO on Linux is actually a userspace threads implementation by glibc and comes with its own limitations (e.g. it's considered slow and doesn't scale well).

These days (2020) hope for doing arbitrary asynchronous I/O on Linux with less pain and tradeoffs is coming from io_uring...

Affianced