I would like to use evented I/O for a proxying application. My present thinking is to fork a thread for each new connection and then to wait for data on either socket in this thread, writing to one or the other socket as needed. There are two API functions I've found for waiting and they each raise some questions: System.IO.hWaitForInput :: Handle -> Int -> IO Bool This function dovetails well with the high-level networking libraries but introduces difficulties because it decodes the stream to check for full characters. If the handle is set to binary mode, are decoding errors still a possibility? Control.Concurrent.threadWaitRead :: Fd -> IO () This function would seem to be closer to the ideal in terms of performance and semantics: it just waits until there are bytes available. However, converting the handle produced by the high-level networking libraries to a file descriptor closes the handle (!). This makes some sense: plucking the descriptor out of a handle doubtless interacts with other users of that handle in an unsafe way. It seems I need to through a very different set of libraries, one based on file descriptors and not handles, to be able to use this function. Ideally, I'd get something like select() on handles, just saying whether there are bytes or not. However, I haven't managed to find anything like that in the standard libraries. -- Jason Dusek () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments