Difference between revisions of "GHC/NewIOManager"

From HaskellWiki
< GHC
Jump to navigation Jump to search
 
 
Line 6: Line 6:
   
 
* remove any non-<tt>base</tt> dependencies so that the code can be acceptable for inclusion into GHC
 
* remove any non-<tt>base</tt> dependencies so that the code can be acceptable for inclusion into GHC
* set up a <tt>darcs</tt> repo instead of the <tt>git</tt> one
 
 
* work out a compatible design that will work for Windows [http://msdn.microsoft.com/en-us/library/aa365198(VS.85).aspx IO completion ports] -- many changes to the other I/O functions may be required here!
 
* work out a compatible design that will work for Windows [http://msdn.microsoft.com/en-us/library/aa365198(VS.85).aspx IO completion ports] -- many changes to the other I/O functions may be required here!
 
* determine which other API changes will be necessary in GHC proper
 
* determine which other API changes will be necessary in GHC proper
Line 12: Line 11:
 
* use the <tt>pipe()</tt> trick GHC currently uses to support waking up the I/O manager from other threads
 
* use the <tt>pipe()</tt> trick GHC currently uses to support waking up the I/O manager from other threads
 
* finish <tt>poll()</tt> / <tt>select()</tt> / <tt>kqueue()</tt> / <tt>epoll()</tt> backends
 
* finish <tt>poll()</tt> / <tt>select()</tt> / <tt>kqueue()</tt> / <tt>epoll()</tt> backends
  +
  +
Low priority:
 
* set up a <tt>darcs</tt> repo instead of the <tt>git</tt> one
   
 
== Resources ==
 
== Resources ==

Latest revision as of 19:07, 27 December 2009

GHC's I/O manager currently uses select() for I/O multiplexing. The select() call requires an walk through the file descriptor list to determine whether the descriptors are ready for reading or writing. We've been wanting to replace this with epoll() (or the equivalent) for years now.

Our work in process can be downloaded here: http://github.com/tibbe/event

Todo list

  • remove any non-base dependencies so that the code can be acceptable for inclusion into GHC
  • work out a compatible design that will work for Windows IO completion ports -- many changes to the other I/O functions may be required here!
  • determine which other API changes will be necessary in GHC proper
  • testing for all platforms
  • use the pipe() trick GHC currently uses to support waking up the I/O manager from other threads
  • finish poll() / select() / kqueue() / epoll() backends

Low priority:

  • set up a darcs repo instead of the git one

Resources