ANNOUNCE - graphics package

[Luke Gorrie]

Joe Armstrong <joe@REDACTED> writes:

>   It turns out that with 20 odd protocol messages one can do *most* of
> the  fun  things  that are  possible  with  X.  The entire  design  of
> virtually all widget  sets (motif, GTK etc) seems  to be predicated by
> the  desire to  simulate  concurrency  with callbacks.  In  ex11 I  do
> *exactly the opposite* and expose the concurrency to the applications.

Is it really concurrency they are simulating?

I think what they're simulating is object-oriented programming. The
callbacks are there to poke in behaviour so that e.g.  "Ok" and
"Cancel" buttons do different things.

I'm very curious to see how this experiment goes though :-). I tried
something similar by making Ermacs a "concurrent Emacs", where a
command could return control to the user but continue working in the
background on some "borrowed" (locked) buffer(s).

The Ermacs `erlang-interaction-mode' is an Erlang shell written as an
Ermacs mode. When you press return it spins off a new process that
borrows the shell buffer until the computation is finished and the
result is inserted. Meanwhile you can keep editing other buffers, but
will be blocked from mucking with that particular one.

However, in practice I think Emacs's event-loop is much better than
Ermacs's concurrency. I don't think Emacs editors have a great deal of
intrinsic concurrency, and introducing it just makes things more
complicated. I wonder if other UIs are similar.

(Also, having multiple activities in a UI makes the "abort what you're
doing now" (C-g) command more confusing. But I'm told some people use
low-level UIs without such basic features ;-)

BTW, Java initially had a multithreaded event-loop (i.e. events
dispatched by N threads at once), but this was a disaster. They
replaced this with an Emacs-like single-threaded event loop. If
another thread wants to do some GUI work then it passes a fun to the
GUI event-thread to run when it's ready (quite Erlangish).

I'm not sure what the lesson of the Java GUI toolkits is, but they
clearly crashed and retreated when they tried concurrency. Maybe ex11
could have more success.

>   This style  of programming  is impossible without  very light-weight
> processes since  it would  be a nightmare  to (say)  fork of a  new OS
> process for every button or label or slider in a GUI ...

I have been pondering lately the weight of OS processes. In Linux 2.6
the scheduler context-switches 1000 times per second (up from 100 in
2.4) without appreciable overhead. Processes seem to be losing weight.

How about an Erlang clone that uses OS processes/IPC directly? I
wonder how far it could get. It certainly wouldn't scale as far, but
maybe it would scale enough for some applications -- my Erlang nodes
rarely have more than a few hundred processes I think. It could be
interesting to be able to use Unix debugging tools like
top/strace/lsof/... directly on a per-process basis.

I'm wondering this after hearing about the Qmail author's programming
style, which seems to strike a balance between Erlang and Unix style
(from what I'm told and have just read in the very good _Art of Unix
Programming_ book).

Cheers,
Luke