On Fri, Feb 03, 2006 at 08:40:27AM -0000, Simon Peyton-Jones wrote:
> The interface can be a library, but (a) what libraries are available is
> part of the language definition and (b) it's hard to build a good
> implementation without runtime support. And the nature of the runtime
> support depends on what the library interface is.
If we had a good standard poll/select interface in System.IO then we
actually could implement a lot of concurrency as a library with no
(required) run-time overhead. I'd really like to see such a thing get
into the standard. Well, mainly it would just be a really useful thing
to have in general. If others think it is a good idea I can try to come
up with a suitable API and submit it to the repo.
My main issue with actually requiring concurrency is that it implies
some very non-trivial runtime overhead. at least as implemented by ghc.
of course, since ghc already uses indirect functions for all of its
thunk evaluations, it effectivly gets the ability to do concurrency 'for
free'. But this is certainly not true of all run-time models. There was
an interesting paper on implementing abstract interpreters that showed
on modern architectures although indirect function calls only are 5-10%
of the instructions executed, they account for well more than half of
the time spent in a program. in ghc generated assembling I am guessing
they are more like 30-40% of calls (the fact that ghc gets such great
performance despite this is quite promising for its future! I hope a
common c-- back end can be developed and shared among haskell
implementations that is particularly good at optimizing the type of code
we like to produce. But I have limited myself to writing one compiler at
a time for the time being :) .)
What I would really like to see come out of this process as it relates
to concurrency are:
the ability to write thread-safe (but not thread using) libraries
portably. which means MVars and foreign annotations but nothing more.
A nice, well thought out standardized poll/select/asynchronous IO
library as part of System.IO. this will fill a much needed gap between
full concurrency and synchronous IO which is currently a void and will
provide just enough run-time support for experimenting with portable
concurrency libraries.
a method of standardizing extensions independent of the language and
getting them approved as "official, optional features", concurrency is
really interesting and I'd hate to bog it down by forcing it to evolve
at the haskell standards pace :)
John
--
John Meacham - ⑆repetae.net⑆john⑈
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
