Concurrency

[John Meacham]

On Tue, Apr 04, 2006 at 02:25:11PM +0100, Simon Marlow wrote:
> On 31 March 2006 22:15, John Meacham wrote:
> 
> > On Fri, Mar 31, 2006 at 04:21:26PM +0100, Simon Marlow wrote:
> >> Great.  Apart from my misgivings about allowing cooperative
> >> scheduling at all, here's a few comments on the proposal:
> > 
> > much much preferable to a standard that not everyone can implement. :)
> > 
> >>   - I wouldn't include threadWaitRead, threadWaitWrite,
> >>     or threadDelay at all.  These can all be implemented using
> >>     FFI, so don't belong in the concurrency library.  Their
> >>     presence is largely historical.
> > 
> > They all have special implementations on a 'epoll' based system.
> > threadDelay turns into the timeout parameter to select, waitread/write
> > turn into the basic building blocks of your epoll wait-list. We
> > definitly want these in the interface as primitves.
> 
> Still not convinced.  Most applications can use the standard IO library
> in a multithreaded program to get I/O multiplexing.  The library might
> be implemented by using a clever epoll/kqueue/whatever interface
> underneath, but I don't see a reason to expose that as a standard
> library.  And it's perfectly reasonable to implement concurrent IO
> without doing any clever epoll stuff: GHC on Windows does just that.
> 
> IMHO, concurrency gives you a way to *avoid* needing an event interface
> in your language.

Oh, it was always my plan to expose the epoll/Event library, it is
something lacking in haskell currently which is a pain. Often, an EDSM
loop is the best way to express an algorithm. Concurrency is great, but
it is far from a panacea.

> 
> > In particular, foregin concurrent calls will most likely be
> > implemented in _terms_ of threadWaitRead on cooperative systems.
> 
> By all means, but that still doesn't mean that threadWaitRead needs to
> be in the standard.

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.

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.

Efficient scheduling is another use. you might want to wait for
several clients to become ready before deciding which one to actually
service.


Basically, they are needed any time the data you are processing is
time-dependent. any time you need to decide what to read or write on the
current conditions rather than what they were when you started the read
or write.


        John


-- 
John Meacham - ⑆repetae.net⑆john⑈