A somewhat satisfactory answer:

The heart of the new GHC IO manager is a kqueue()/epoll() event loop. So I would expect anything which can be built on top of this to be eligible -- if not now, then later. In particular this means:

File IO

Network IO

The code (I looked at it some months ago and things might have changed) also contains support for registering and running timeouts of various kinds through a priority (search) queue. This suggest that most sleep -like calls can also be piggybacking on the interface.

About Database Access: sure, you often access the database through a network IO socket so calling forkIO and doing DB access in a separate thread should be doable, fast, and safe. Communicating data back to the rest of the application can be done with one of the concurrency means, Chan or STM.TChan .

I don't think there are kinds of IO where the manager has to resort to blocking per se, but I can imagine that some libraries may circumvent the new IO manager and go straight for the jugular. They will, of course, block.