[9fans] [plan9port] graphics

[9fans] [plan9port] graphics

[Russ Cox]

[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

Re: [9fans] [plan9port] graphics

[Jack Johnson]

On 6/28/06, Russ Cox <rsc@swtch.com> wrote:
> My hope is that doing things the Official Unix Way inside
> devdraw will eliminate the problems people have reported.

Thanks, Russ!

Just out of curiosity, have you seen any noticeable difference in
performance, good or bad?

-Jack

Re: [9fans] [plan9port] graphics

[Russ Cox]

> Just out of curiosity, have you seen any noticeable difference in
> performance, good or bad?

No.  Except my own performance, since I don't have to restart
my 9term windows and my acme multiple times per day anymore.

Russ

Re: [9fans] [plan9port] graphics

[Roman Shaposhnick]

On Wed, Jun 28, 2006 at 10:46:29AM -0700, Russ Cox wrote:
> 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.

  This sounds interesting enough, but what's the "language"
  an application is supposed to talk to devdraw binary in ?
  Is it just the draw(3) ?

Thanks,
Roman.

Re: [9fans] [plan9port] graphics

[David Leimbach]

On 6/28/06, Roman Shaposhnick <rvs@sun.com> wrote:
> On Wed, Jun 28, 2006 at 10:46:29AM -0700, Russ Cox wrote:
> > 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.
>
>   This sounds interesting enough, but what's the "language"
>   an application is supposed to talk to devdraw binary in ?
>   Is it just the draw(3) ?
>
> Thanks,
> Roman.
>

I'd think you're still supposed to talk in draw(3) for portability's
sake right? :-)

Some protocols don't have to be fully open, but it might be
interesting to know about them.

Dave

Re: [9fans] [plan9port] graphics

[quanstro]

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.
> 

Re: [9fans] [plan9port] graphics

[Russ Cox]

> 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?

i still think that the right long-term solution is
a single devdraw that can handle many windows.
this was easier to get running and get right
(which is not to say that it worked the first time!),
and i don't want to waste any more time on x
than i already have.

responding to earlier questions, you're still supposed
to use draw(3).  drawfcall(3) is subject to change.

russ

Re: [9fans] [plan9port] graphics

[Roman Shaposhnick]

On Thu, Jun 29, 2006 at 08:36:41AM -0700, Russ Cox wrote:
> responding to earlier questions, you're still supposed
> to use draw(3).  drawfcall(3) is subject to change.

  Thanks. I was just confused that you didn't mention
  draw(3) explicitly and had to resort to euphemisms
  like "protocol" ;-)

Thanks,
Roman.

Re: Re: [9fans] [plan9port] graphics

[andrey mirtchovski]

i'm having an issue with the new devdraw code. while displaying acme
to a remote terminal, killing the window acme is in without Exiting
acme outputs:

devdraw: X I/O error

but does not kill the process. further ctrl+C outputs:

9pserve unix!/tmp/ns.andrey.localhost:10/acme: Jul 12 09:10:30.471
note: interrupt
acme: interrupt

it's the same for other devdraw apps such as stats. this happens when
displaying both locally and remotely to OSX.