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