Concurrency

[Simon Marlow]

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.