On Fri, Feb 03, 2006 at 01:00:32AM -0800, John Meacham wrote:
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
Maybe this is just me being dense, but how is poll or select concurrency? There is no multiprocessing involved; it is simply a more efficient way to find which file descriptors are ready for some I/O action. 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.
the ability to write thread-safe (but not thread using) libraries portably. which means MVars and foreign annotations but nothing more.
Yes. Plus, I'd say, the presence of threading primitives that return certain well-defined exceptions or something along those lines, so that it's not necessary to know whether multithreading is supported at compile time.
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.
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) 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. -- John