Priorities

On 03 February 2006 16:03, John Goerzen wrote:
> I know, of course, that Java green threads and Haskell forkIO threads
> are called "threads", but I personally believe its misleading to call
> it concurrency -- they're not doing more than one thing at a time.
We use the terms "concurrency" and "parallelism" to mean two completely
distinct concepts, as others have pointed out.
Concurrency means structuring your program as multiple independent
threads of control, which are independent of each other and can interact
in non-deterministic ways. Parallelism means running computations
simultaneously on multiple processors - you can run a concurrent program
in parallel, but you can also use parallelism to speed up
single-threaded programs.
> Well, I must admit to being confused at the present state of things.
>> Right now, we have forkIO, which seems, to me, like a fancy wrapper
> around select or poll. It's very nice, really.
>> I'm not clear, though, on how to integrate other C libraries that have
> their own async I/O systems into all of this. (For instance, LDAP or
> SQL libraries)
We do have a nice story for all this, probably nicer than in any other
language implementation you'll come across. GHC gives you both the
performance from lightweight threads, combined with the ability to use
OS-level concurrency for invoking FFI calls that might block, such as
the SQL or LDAP libraries you refer to . In these cases you don't have
to incorporate the library's file descriptors into one Giant Select, you
just make a blocking call to the library. The runtime makes sure it
happens in a different OS thread, so it doesn't block any of your
Haskell threads. Lightweight threads by default, OS threads when
needed.
> The exact interaction between FFI, forkIO, forkOS, etc. is, to me,
> extremely vague right now. It also seems much more complex than in
> other languages, and perhaps varies from one Haskell implementation to
> the next.
There is only one Haskell implementation that really does concurrency.
Hugs has cooperative concurrency, but that's pretty limited (I don't
think it does I/O, for example).
The story is more complex than in other languages, but I think it's
largely a matter of documentation, the design has been very carefully
thought out:
http://www.haskell.org/~simonmar/papers/conc-ffi.pdf
I'm glad you pointed out that you find the situation confusing, I'll
definitely try to improve the documentation.
Cheers,
Simon