Priorities

[John Meacham]

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⑈