--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
+<html>
+ <head>
+ <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
+ <title>The GHC Commentary - Non-blocking I/O on Win32</title>
+ </head>
+
+ <body BGCOLOR="FFFFFF">
+ <h1>The GHC Commentary - Non-blocking I/O on Win32</h1>
+ <p>
+
+This note discusses the implementation of non-blocking I/O on
+Win32 platforms. It is not implemented yet (Apr 2002), but it seems worth
+capturing the ideas. Thanks to Sigbjorn for writing them.
+
+<h2> Background</h2>
+
+GHC has provided non-blocking I/O support for Concurrent Haskell
+threads on platforms that provide 'UNIX-style' non-blocking I/O for
+quite a while. That is, platforms that let you alter the property of a
+file descriptor to instead of having a thread block performing an I/O
+operation that cannot be immediately satisfied, the operation returns
+back a special error code (EWOULDBLOCK.) When that happens, the CH
+thread that made the blocking I/O request is put into a blocked-on-IO
+state (see Foreign.C.Error.throwErrnoIfRetryMayBlock). The RTS will
+in a timely fashion check to see whether I/O is again possible
+(via a call to select()), and if it is, unblock the thread & have it
+re-try the I/O operation. The result is that other Concurrent Haskell
+threads won't be affected, but can continue operating while a thread
+is blocked on I/O.
+<p>
+Non-blocking I/O hasn't been supported by GHC on Win32 platforms, for
+the simple reason that it doesn't provide the OS facilities described
+above.
+
+<h2>Win32 non-blocking I/O, attempt 1</h2>
+
+Win32 does provide something select()-like, namely the
+WaitForMultipleObjects() API. It takes an array of kernel object
+handles plus a timeout interval, and waits for either one (or all) of
+them to become 'signalled'. A handle representing an open file (for
+reading) becomes signalled once there is input available.
+<p>
+So, it is possible to observe that I/O is possible using this
+function, but not whether there's "enough" to satisfy the I/O request.
+So, if we were to mimic select() usage with WaitForMultipleObjects(),
+we'd correctly avoid blocking initially, but a thread may very well
+block waiting for their I/O requests to be satisified once the file
+handle has become signalled. [There is a fix for this -- only read
+and write one byte at a the time -- but I'm not advocating that.]
+
+
+<h2>Win32 non-blocking I/O, attempt 2</h2>
+
+Asynchronous I/O on Win32 is supported via 'overlapped I/O'; that is,
+asynchronous read and write requests can be made via the ReadFile() /
+WriteFile () APIs, specifying position and length of the operation.
+If the I/O requests cannot be handled right away, the APIs won't
+block, but return immediately (and report ERROR_IO_PENDING as their
+status code.)
+<p>
+The completion of the request can be reported in a number of ways:
+<ul>
+ <li> synchronously, by blocking inside Read/WriteFile(). (this is the
+ non-overlapped case, really.)
+<p>
+
+ <li> as part of the overlapped I/O request, pass a HANDLE to an event
+ object. The I/O system will signal this event once the request
+ completed, which a waiting thread will then be able to see.
+<p>
+
+ <li> by supplying a pointer to a completion routine, which will be
+ called as an Asynchronous Procedure Call (APC) whenever a thread
+ calls a select bunch of 'alertable' APIs.
+<p>
+
+ <li> by associating the file handle with an I/O completion port. Once
+ the request completes, the thread servicing the I/O completion
+ port will be notified.
+</ul>
+The use of I/O completion port looks the most interesting to GHC,
+as it provides a central point where all I/O requests are reported.
+<p>
+Note: asynchronous I/O is only fully supported by OSes based on
+the NT codebase, i.e., Win9x don't permit async I/O on files and
+pipes. However, Win9x does support async socket operations, and
+I'm currently guessing here, console I/O. In my view, it would
+be acceptable to provide non-blocking I/O support for NT-based
+OSes only.
+<p>
+Here's the design I currently have in mind:
+<ul>
+<li> Upon startup, an RTS helper thread whose only purpose is to service
+ an I/O completion port, is created.
+<p>
+<li> All files are opened in 'overlapping' mode, and associated
+ with an I/O completion port.
+<p>
+<li> Overlapped I/O requests are used to implement read() and write().
+<p>
+<li> If the request cannot be satisified without blocking, the Haskell
+ thread is put on the blocked-on-I/O thread list & a re-schedule
+ is made.
+<p>
+<li> When the completion of a request is signalled via the I/O completion
+ port, the RTS helper thread will move the associated Haskell thread
+ from the blocked list onto the runnable list. (Clearly, care
+ is required here to have another OS thread mutate internal Scheduler
+ data structures.)
+
+<p>
+<li> In the event all Concurrent Haskell threads are blocked waiting on
+ I/O, the main RTS thread blocks waiting on an event synchronisation
+ object, which the helper thread will signal whenever it makes
+ a Haskell thread runnable.
+
+</ul>
+
+I might do the communication between the RTS helper thread and the
+main RTS thread differently though: rather than have the RTS helper
+thread manipluate thread queues itself, thus requiring careful
+locking, just have it change a bit on the relevant TSO, which the main
+RTS thread can check at regular intervals (in some analog of
+awaitEvent(), for example).
+
+ <p><small>
+<!-- hhmts start -->
+Last modified: Wed Aug 8 19:30:18 EST 2001
+<!-- hhmts end -->
+ </small>
+ </body>
+</html>
projects / ghc-hetmet.git / blobdiff