[9fans] [plan9port] graphics

["Russ Cox" <rsc@swtch.com>]

[Short version: new graphics code.  If you've seen problems
before, try the new code.  If you haven't seem problems,
keep an eye out for them.  Thanks.]

Over the weekend I restructured the way graphics programs
run under Plan 9 from User Space.  I'd been seeing frequent
mysterious hangs and X I/O errors in multithreaded graphics
programs running on Linux SMP machines using pre-NPTL
threading.

In Plan 9, a typical graphics program might have a proc
reading the keyboard, a proc reading the mouse, and another
proc executing draw operations with writes to files in
/dev/draw/.

I tried to preserve this model in Plan 9 from User Space,
using pthreads or explicitly-created shared-memory threads
on systems where pthreads wasn't good enough (e.g., Linux
pre-NPTL).  I allocated multiple connections (Displays) to
the underlying X server and gave one to each proc, though
there were one or two places where I had to cheat, letting
one proc send an asynchronous message to a Display that
another proc was reading.  I still don't know whether these
cut corners are what caused the trouble or whether there are
deeper problems with truly multithreaded X clients.

Whatever the reason, some combinations of X library,
X server, C library, threading library, and Linux kernel can't
seem to handle the way the ported Plan 9 programs were using
the interface.  My 9term windows would suddenly stop
accepting keyboard input, or stop accepting mouse input and
redraw requests.  Acme would do the same, though less
frequently.

Over the weekend I shuffled things around.  Instead of
linking X code into every program, there is now a single
program, called devdraw, that contains X interface code.
Graphical programs now fork and exec a devdraw and then
speak a simple protocol to its standard input and standard
output to read from the keyboard and mouse and draw on the
screen.  Devdraw is not a threaded program.  It runs on the
standard system stack and uses select(2) to manage its two
inputs.  It uses only a single connection to the X server.
My hope is that doing things the Official Unix Way inside
devdraw will eliminate the problems people have reported.

The main visible side effect of this change, other than
hopefully increased stability, is that if you want to run a
graphics program you'll need to have a devdraw binary
in your path.  If you copy samterm somewhere, you'll need
to copy devdraw too.

There are a few other cleanups and bug fixes.  See the
CHANGES file for more.

Please let me know of any problems.

Thanks.
Russ