Linux offers some async io features, but does not offer async throughout.
In a fully async platform you would be able to do general-purpose programming without ever needing to use multithreading.
Example of a situation you can't do in linux: have a program doing select(2)
or equivalent on both keyboard input and network input, in a single thread.
Since linux does not support this, you are steered to adapt solutions that are more complicated than a pure async model would be,
* Spin constantly looking for activity. These heats up your computer and uses battery.
* Have short timeouts on epoll, and then glance for keyboard input. This leads to jerky IO.
* Have child processes block on these operations and use unix domain sockets to feed back to a multiplexor (fiddly, kernel contention).
* The child-process thing but with shmem (fiddly)
* Something equivalent to the child process thing, but with multiple threads in a single process. (fiddly)
You would think that x-windows might help out here. What if you had a socket to X, and then multiplexed on that, instead of looking for keyboard input from a terminal? This opens new issues: what if X has only written half of an event to your socket when select notifies you? Will your X library handle this without crashing?
Rurban's comment above is correct. Linux is not async throughout.
On OSs that offer kevent you can get a fair bit further, but (I believe) you
still can't do file creation/deletion asynchronously.
This is broken. (Woke from a sleep, face-palmed. I have been in Windows IPC land and got my wires crossed, sorry.) In linux you can select on both the stdin fd and network sockets in a single call. There is a way to get a fd for AIO also. AFAIK the sync-only file creation/deletion stands.
Linux is async throughout since it can do task switching on blocking.
You're not the only task running.
Or do you expect Linux to pause the system when you read a file until the DMA is answered?
Linux itself is fully async, anything blocking (even interrupts to some extend) will be scheduled to resume when the reason it blocked is gone or alternatively check back regularly to resume.
A program running on Linux can do a lot of things async as mentioned via POSIX AIO. It's not impossible, go seems to do fine on that front too (goroutines are put to sleep when doing blocking syscalls unless you do RawSyscall).
The conclusion that lack of 100% asynchronity means it can't be properly concurrent is also wrong. As evident that sending something to disk also doesn't not halt the kernel.
In a fully async platform you would be able to do general-purpose programming without ever needing to use multithreading.
Example of a situation you can't do in linux: have a program doing select(2) or equivalent on both keyboard input and network input, in a single thread.
Since linux does not support this, you are steered to adapt solutions that are more complicated than a pure async model would be,
* Spin constantly looking for activity. These heats up your computer and uses battery.
* Have short timeouts on epoll, and then glance for keyboard input. This leads to jerky IO.
* Have child processes block on these operations and use unix domain sockets to feed back to a multiplexor (fiddly, kernel contention).
* The child-process thing but with shmem (fiddly)
* Something equivalent to the child process thing, but with multiple threads in a single process. (fiddly)
You would think that x-windows might help out here. What if you had a socket to X, and then multiplexed on that, instead of looking for keyboard input from a terminal? This opens new issues: what if X has only written half of an event to your socket when select notifies you? Will your X library handle this without crashing?
Rurban's comment above is correct. Linux is not async throughout.
On OSs that offer kevent you can get a fair bit further, but (I believe) you still can't do file creation/deletion asynchronously.