On 04 April 2006 20:07, John Meacham wrote:
Here are a couple of uses. We need waiting routines for every interesting event, they are darn useful, and they admit a very optimized implementation.
A C library which reads a file descriptor, calling threadWaitRead beforehand and then the call is much more efficient than calling the library directly.
As long as you can guarantee not to be preempted between threadWaitRead and the foreign call, yes.
A consumer-producer set up, you don't want to read into core memory the producers data until you are sure you have somewhere to write it to, so you have a 'threadWaitWrite-read-write' loop.
UI design, a common issue is displaying continuously updating information on the screen. You communicate with the X11 server via a pipe, so it is possible to just completely fill the X11 buffer with drawing requests and get a backlog killing your apps responsibility. also, by the time these backloged events actually get to the screeen they may be out of date and your app quickly crashes and burns if your incoming data rate exceeds the speed at which you can draw to the screen.
Concurrency admits a nice solution, you have your thread that generates the interesting info, (say, reading data from a DSP), continually updating a shared location. your drawing routine is in a 'threadWaitWrite-readlocation-drawit' loop. notice that threadWaitWrite is needed because otherwise you would be forced to send outdated data to the screen if you couldn't separate what you write from when you write it.
A C call that uses a file, but expects some precondition to be set before it can be run. One that I ran into is a curses library that waited for user input, but wanted the screen to be cleared before it could be run. clearing the screen right away would have left the user sitting staring at a blank screen with no instructions until they pressed a key, the right thing to do was to do a threadWaitRead, clear the screen, then call the routine.
Sure, there's no problem with having operations that just wait for events. We already have System.IO.hWaitForInput, suppose we added System.IO.hWaitForOutput. That satisfies your requirements for threadWaitRead/threadWaitWrite, right? The point is, I believe there's nothing special about these event-waiting functions. If you want to wait for several events, then you fork a thread for each one and send the results down a shared channel. The implementation might well do something clever to avoid needing one OS thread per waiting event, or it might not. I can believe there are situations where the programmer might want more direct access to an event model for efficiency reasons, but I don't believe that this is essential functionality that needs to be in Haskell'. Cheers, Simon PS. I don't think hWaitForInput should have the timeout argument.