Thank you, especially for your notes on aio_. As promised, I sent you something by email, but know that your comment is worth more than that.
Fast scrolling in large buffers (especially complex XML files opened in nxml-mode)
I think nxml-where.el is guilty for the slow scrolling in large xml files. I wanted to offload that to another thread, but a simpler solution is to only update the path post-scroll.
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.
Fast scrolling in large buffers (especially complex XML files opened in nxml-mode)
I think nxml-where.el is guilty for the slow scrolling in large xml files. I wanted to offload that to another thread, but a simpler solution is to only update the path post-scroll.