Re: [9fans] [plan9port] graphics

[quanstro@quanstro.net]

when this came up a while ago, you suggested one devdraw
server per namespace.  after some consideration i convinced
myself you were right.  programs like rio could be much closer
to the plan 9 source.  lately i've been considering writing an
X server extension implementing devdraw.  (i realize this might
be problematic on osx.) 

why did you choose to run 1 devdraw per graphical program?

- erik

(i haven't had X connection problems with nptl.  i thought linuxthreads
was pretty much a thing of the past)

On Wed Jun 28 12:47:41 CDT 2006, rsc@swtch.com wrote:
[...]
> 
> 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.
> 
[...]
> 
> 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.
>