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⑈