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, [EMAIL PROTECTED] 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. >
