Concurrency

[Simon Marlow]

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.

> 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.

Cheers,
	Simon