[GHC] #7353: Make system IO interruptible on Windows

[GHC]

#7353: Make system IO interruptible on Windows
---------------------------------+------------------------------------------
    Reporter:  joeyadams         |       Owner:                             
        Type:  bug               |      Status:  new                        
    Priority:  normal            |   Milestone:  7.8.1                      
   Component:  libraries/base    |     Version:  7.6.1                      
    Keywords:                    |          Os:  Windows                    
Architecture:  Unknown/Multiple  |     Failure:  Incorrect result at runtime
  Difficulty:  Unknown           |    Testcase:                             
   Blockedby:                    |    Blocking:                             
     Related:                    |  
---------------------------------+------------------------------------------

Comment(by simonmar):

 I'm not an expert on Windows async I/O and I haven't read all the
 documentation thoroughly, so please take my opinions with a pinch of salt.

 I'm personally not concerned about being able to implement
 `threadWaitRead`: I think of that as an internal API used to implement
 blocking I/O.  We only have it because this API happens to work with
 select()/epoll().  If the underlying OS interfaces don't map well to
 `threadWaitRead`, then we should redesign the API at that level, rather
 than going to a lot of trouble to emulate `threadWaitRead`.

 It looks like your plan would work, but I wonder whether we ought to go to
 IOCP instead.  Regarding the two points you make about IOCP:

  * no way to wait for readiness: as I said, I don't think we need
 `threadWaitRead`, and `IODevice.ready` can be implemented another way (we
 already have `fdReady` for this)

  * This is slightly annoying.  One solution is to make the I/O manager a
 bound thread, and hand off all I/O operations to that thread, then we just
 ensure that this thread never exits.  Or if the hand-off to a bound thread
 is too expensive, we will need a separate mechanism to prevent worker
 threads that have outstanding I/O requests from being terminated - a
 simple refcounting scheme will probably work fine here.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7353#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler