From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Wed, 28 Jun 2006 10:46:29 -0700 From: "Russ Cox" To: 9fans <9fans@cse.psu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [9fans] [plan9port] graphics Topicbox-Message-UUID: 6f2e6e10-ead1-11e9-9d60-3106f5b1d025 [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