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 _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
