From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Wed, 28 Jun 2006 23:27:36 -0500 From: quanstro@quanstro.net To: 9fans@cse.psu.edu Subject: Re: [9fans] [plan9port] graphics In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 7024245e-ead1-11e9-9d60-3106f5b1d025 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. >