On Unix, there is no API to let applications do fully asynchronous I/O in an easy and portable way.
The reason why this is so important is that GUI applications need to be responsive all the time. If a GUI application is blocked during a long synchronous file operation, the user cannot stop the operation, nor perform any other task with the same application. This is especially important for a file manager, which needs to be able to perform multiple I/O tasks in parallel without taking control away from the user.
One of the ways of dealing with asynchronous I/O, i.e. using the select() system call, does not work with all the operations; for example, there is no way to make an asynchronous gethostbyname(), open() or stat() without complicated hacks.
Unix programmers could also use POSIX threads for performing asynchronous operations, but thread programming is very error-prone and can easily lead to problems. Writing a threaded application requires more programming skills writing a non-threaded one, and in the free software world it is very important to make things easy for programmers.
Moreover, POSIX threads are not fully portable across different platforms, as not all implementations are reliable and efficient.
Finally, although a POSIX API for asynchronous I/O exist, it is not implemented on all systems and does not work with all system calls. For example, you cannot execute the open() nsystem call in an asynchronous fashion. Moreover, this API does not fit nicely in the event-based model of GUI systems; consequently, it is not suitable for rapid development of GUI applications.
What we need for asynchronous operation is an easy to use API that hides most of the details from the programmer and integrates nicely with the existing GUI toolkits. The API should give a better abstraction for doing async I/O, in the most simple way possible.