Unfortunately, for most mortals, thread programming is just Too Hard
to get right... Even in Python -- every time someone gets into
serious thread programming, they send me tons of bug reports, and half
of them are subtle bugs in the Python interpreter, half of them are
subtle problems in their own understanding of the consequences of
multiple threads...
I've been investigating multithreaded runtimes quite a bit lately
in the context of building distributed hypermedia applications.
Here's my list of critical features for a language/runtime for
building distributed hypermedeia applications:
* Interfaces/modules
the applications tend to be large. Interfaces and
modules help a lot with complexity management and reuse
* Thread interface
GUI callbacks, client/server stuff, etc. fits
well with threads
* Exceptions
counting on folks to check error codes is a disaster
waiting to happen
* Safe programming support (garbage collection, type safety)
The bulk of application functionality can and should
be coded this way
* Systems programming suport (unsafe stuff, for fast bit-twiddling)
Gotta have it.
* TCP/IP networking interface
* flatten/serialize/pickle interface
for building RPC systems, hypermedia databases,
and for just saving state across sessions
* Objects with Inheritance
* Object-oriented Reader/Writer interface (files, sockets, pipes)
* Window/Menu/Mouse API
In the ideal case, the Thread interface would be implemented top to
bottom: multi-processor support, re-entrant C library (including cruft
like gethostbyname, etc.). Modula-3 on solaris would nearly fit the
bill, if the M3 threads exploited solaris's SMP features. M3 on
Windows-NT would fit the bill if the GUI library, treslte, were
working.
But we'd all like to be writing code that works on X, Mac and Windows,
and interoperates with all the third-party C-callable API's for
databases and such.
The leader in interoperability is probably Tcl/Tk. There's Tcl/Tk glue
for everything. But Tcl falls down on interfaces, exceptions, garbage
collection and objects. [And I just don't like it, and I'm not
interested in discussing it any further, despite its many merits,
thank you.]
If we're willing to give up preemptive multitasking, I think there's
some happy middle ground.
Options:
I. python+tkinter (but do something like the perl5 or STk folks did
and get rid of Tcl). Add _cooperative_ multithreading to the
interpreter (just malloc() multiple stacks and longjump() between
them, I think).
Obsolete the __builtin__.open and the other stdio-based i/o interfaces
with thread-aware i/o interfaces, like the Modula-3 Rd/Wr interfaces
that (1) can raise Thread.Alerted, and (2) use non-blocking i/o and
select() to let runnable threads run.
Granted, you'd still have to sprinkle Thread.Yield() calls inside any
compute-bound tasks, but that's a lot easier than hacking closures
with objects or managing thread state yourself the way C/Motif/Xt
programming is done.
II. STk.
Not sure what to do for an interface/module system, but maybe
one could be hacked in.
Develop an object-oriented analog to scheme's ports, and use that for
networking, pipes, file i/o, etc. Again, this i/o stuff must be
thread-aware.
Scheme's continuations, dynamic-wind, and all that are plenty powerful
enough to support exceptions, but we would need to develop consistent
usage of an exception model across these libraries/interfaces.
Borrowing the one from Modula-3 like python did would be a good start.
III. Scheme-48/scsh. Nice module and macro systems and lightning fast,
but the foreign function interface needed a lot of work, last I
checked (release 0.36). For a reasonable FFI, a radically different
garbage collection system like SCM/guile's would probably be
necessary.
Same story as STk for thread-aware i/o (and hence networking) interfaces.
And of course the Tk glue for scheme48 isn't done yet (is it?).
And like the exceptions story above, we'd want to choose and
consistently use some OOP model.
IV. Winterp (XLisp + Motif). I haven't looked at this for a while,
but it might support this programming model.
The Tk stuff is tied to X platforms. For now anyway... I don't know
how much of the dependency shows up in the API versus how much is just
in the implementation. The point is that you could write code to the
Tk API, and it might work on Windows and Mac pretty soon. Or maybe
there are three different GUI API's, or maybe somebody develops a
Stdwin-style portable API.
But even if you have to build client applications using
platform-specific GUI APIs, you could still build servers and a lot of
the core functionality in portable code.
In a perfect world, modules written in any of these languages (as well
as smalltalk and perl, maybe) would work together in one address space
with some sort of glue like the ILU (InterLanguage Unification)
project at Xerox or Apple's OSA (Open Scripting
Architecture). Cooperative multitasking simplifies this somewhat. The
issue of heap management is still tricky. Ideally, there would be one
big happy garbage collected heap. But in practice, that looks pretty
scary.
Even if these things can't fit in the same address space for a while,
they ought to interoperate on some sort of "desktop message buss" like
AppleEvents, OLE 2, or RPC system like CORBA or DCE.
Anyway... building WWW libraries, clients, and servers is an obvious
application for this sort of thing. How many HTML, URL, CGI, and HTTP
libraries are floating around right now? Not that there should be One
True Library, but a little more commonality in programming models
would be nice.
For example, the CGI interface is pretty inefficient (very very
inefficient, in fact.) Simon Spero proposed some "BGI" -- binary
gateway interface a while back. It involved dynamic linking and he was
talking about a tcl support module for starters. An ILU-based analog
would be handy.
And after all they crying to "rewrite Mosaic in Tcl," there's till no
"web client for programmers" that supports anywhere near the
functionality of Mosaic or NetScape.
I cobbled up something up a while ago with python and its Xt/Motif
support glue: I added the html widget from Mosaic and a couple of the
modules from CERN's libwww, patched suitably to match python's runtime
system. It worked a little bit, but it's not worth distributing due to
Motif/Mosaic licensing restrictions and the general instability of the
thing. The reason I quit working on it was that it didn't have
"interruptable I/O" because I was using python's networking code. I
think cooperative multitasking might be just the trick...
Dan
-- Daniel W. Connolly "We believe in the interconnectedness of all things" Software Engineer, Hal Software Systems, OLIAS project (512) 834-9962 x5010 <connolly@hal.com> http://www.hal.com/%7Econnolly