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
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
