It's also worth pointing out that Emacs and Emacs Lisp need not be multithreaded in order to implement specific asynchronous operations. If aio did not exist, there's nothing stopping you from creating a thread (from C), doing your blocking save there (and nothing else), and sending a note back to the lisp side when it's done. It's generic threading that adds complexity, because that would require all state-changing operations to be threadsafe, which can be very difficult to "bolt on" to a complex system like Emacs. (Not to mention locking overhead; see Python's GIL debate.)
A good example of this approach is the 0MQ messaging library. While it is internally threaded, it does not care what the application does about thread safety; there is no way that you can ever "see" its threads. It simply requires that you pass ownership of blocks of memory to the library, thus avoiding locking and issues of thread safety while still using threads.
It's also worth pointing out that Emacs and Emacs Lisp need not be multithreaded in order to implement specific asynchronous operations. If aio did not exist, there's nothing stopping you from creating a thread (from C), doing your blocking save there (and nothing else), and sending a note back to the lisp side when it's done. It's generic threading that adds complexity, because that would require all state-changing operations to be threadsafe, which can be very difficult to "bolt on" to a complex system like Emacs. (Not to mention locking overhead; see Python's GIL debate.)
A good example of this approach is the 0MQ messaging library. While it is internally threaded, it does not care what the application does about thread safety; there is no way that you can ever "see" its threads. It simply requires that you pass ownership of blocks of memory to the library, thus avoiding locking and issues of thread safety while still using threads.