On Fri, Mar 31, 2006 at 04:29:59PM -0600, Taral wrote:

On 3/31/06, John Meacham wrote:

...

...

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

And they're all a pain because they don't take sets of files, only single ones. Can we please have something like:

threadWait :: Timeout -> [Handle] -> IO ?

Oh, that is definitly planned as part of an 'epoll' interface I have been calling Event. depending on the compiler, Concurrent might be implemented on top of Event or Event might be implemented on top of Concurrent :) In any case, I left it out of the proposal here because it is relatively orthogonal (from a design, not an implemenatition point of view) but I definitly think it should exist. John -- John Meacham - ⑆repetae.net⑆john⑈

On Mon, Apr 03, 2006 at 11:38:08AM +0100, Ross Paterson wrote:

On Fri, Mar 31, 2006 at 01:15:03PM -0800, 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. :)

Are there potential users for the compromise interface? I had the impressions that those wanting concurrency needed the fairness guarantees.

quite the opposite IMHO. I think for most uses cooperative implementations will be not just just fine, but preferable. We really shouldn't call it a compromise interface, cooperative threading is often considered superior to pthreads/pre-emptive threading for a wide variety of tasks. After a lot of experience writing pthreads code from both the OS and application side, I find I agree. cooperative state-threads should always be the way to go by default when writing new code unless you absolutely need one of the features of pre-emptive threading. the tasks for which state-threads work well for are IO bound multiplexing tasks, pthreads are better for CPU-bound tasks. However, most uses of concurrency are for programs that interact with the user or the external world, as in they wait for an event from a variety of sources and respond to it quickly. The limiting factor isn't processing power, but how fast the events come, how fast you can redraw the screen, your network speed, etc. exactly what state-threading is best at. Most CPU bound tasks tend to be batch processing type things like compilers, which don't need concurrency to begin with. some info on the advantages and tradeoffs http://state-threads.sourceforge.net/docs/st.html although written from the point of view of network servers, a lot is relevant to other fields. Ideally, I'd like to provide both in jhc. But cooperative is a whole lot of bang for the buck. John -- John Meacham - ⑆repetae.net⑆john⑈