Priorities

[John Goerzen]

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