On Fri, Feb 03, 2006 at 10:03:08AM -0600, John Goerzen wrote:
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.
Yeah, it doesn't. however I thought I'd bring it up becauese it is related and is a hole in the current haskell set up. even on implementations with concurrency such a thing is useful as many tasks actually are easier to implement by hand this way when you need fine control over scheduling and whatnot. It's not so much that it's "a more efficient" way as its the only way for any serious application. GHCs concurrency is a nice interface to it, but it is quite high-level and access to the functionality at a medium level in a standardized way would be quite beneficial and allow all the state threaded style programs without necesarisy needing full blown concurrency. Also, providing hPoll is as simple as any FFI wrapper with no implemenation consequences othen than additions to the library so it is quite a bargain indeed for what you get.
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.
this whole field is rife with ambiguous terminology. it has already been a source of confusion several times. I think 'state-threads' are the accepted term for this sort of thread, but am unsure.
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.
It would be odd to have routines in the standard that are only standardized to fail :). We couldn't include those in the standard without saying what their correct behavior is when they worked, which is exactly the task I don't think we can acomplish. Actually, I think it would be difficult to even specify what those primitives are, let alone their exact semantics. Also, I can't think of any reason you would ever want to defer such a decision to run time. either your program needs concurrency and thus should fail at compile time if it isn't available or it just needs to be concurrent-safe in which case it will succeed and work portably because we have included the primitives needed to allow that.
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)
this is a well known issue even outside of haskell land. various solutions have evolved, the glib main loop, liboop, libevent, if ghc were to switch to one then that would allow some sort of interoperability but none are perfect, and each is mutually exclusive in general. this is another reason I feel a hPoll is important, because its low level control is often needed for interacting with other libraries in tricky situations like this.
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.
I am positive it varies, even if there were a (somewhat odd) concerted effort to emulate ghcs behavior, I doubt others would get it right any time soon. It is just such a tricky field! All languages have issues here, some are better at hand waving them away though or just ignoring them. John -- John Meacham - ⑆repetae.net⑆john⑈