- Glib Main Event Loop (can be used without GTK+)
- Java Event dispatching thread (can not be used without AWT)
- Microsoft Windows Message loop (can not be used without a MSWindows GUI)
Because not doing blocking IO in the event loop thread is difficult currently lots of applications in every widget toolkit have this problem. See this post by Havoc Pennington of GNOME fame "SYNCHRONOUS IO NEVER OK"
One way to fix this problem would be to have a way of preventing any blocking call from executing inside the event loop by either logging a warning or just aborting the application when debugging it.
Many people do not care too much about executing blocking code in the event loop because they think the call will run fast and the user will not notice the GUI has blocked. But that reasoning begins to break when the user has an scenario where files are on slow NFS, network or just slow permanent storage. Then the application has to be fixed for that scenario (like pidgin: stop doing blocking file IO and Non-blocking Logging Features)
One other problem is that even widget toolkits have some functions (or methods) that block for IO and are not even marked for so. There is also lack of good non blocking interfaces in operating systems (many still do not scale well enough with the number of events or are too messy to program)
Even functions as open() can block for IO since it has to either check for file existence and permissions for open and create the file entry if the file is open for writing. So, currently if you do not want to block your UI for IO you have to put all file management (open, read, write, close, ...) in a separate thread.
There is hope for better event based development with in kernel features like Kernel Asynchronous I/O (AIO) Support for Linux but that is only the first step since any kernel call inside the event dispatching thread should not block under any circumstances.
I personally think event-driver programming is the way to develop any program so I am committed to fix any issue that makes this problem fade.