--- Roland Mainz <[EMAIL PROTECTED]> wrote: > Jon Smirl wrote: > > > glxProxy effectively would put the GL rendering in its own thread. > And > > > nothing necessarily prevents us from creating a new thread for > in-server DRI. > > > > > > If the rendering is properly encapsulated, then making it > multicore-friendly > > > is cheap and easy; if libglx is redone such that both in-process and > > > out-of-process indirect GL are possible, then the rendering is > probably > > > pretty close to being properly encapsulated. > > > > > > Not disagreeing with you, just saying that discussion is quite a bit > down the > > > line ;). > > > > Why is this so different that what a local process does right now? For > > the remote GLX user split off a new process, it uses DRI to do all of > > it's drawing and then calls back into the server for GLX. A more > > efficient scheme would be for the server to directly run GLX calls > > when received from the remote user and then ship all of the GL call > > off to the second process. > > The idea of forking a complete new process worries me a lot... why is it What's the problem, if it's only done at client connect(read as once in a while)?
> neccesary to use a new process here and no new thread ? A thread could > communicate much easier with the main Xserver thread than a fully-blown > new process and would even share the same memory mappings... What about root privs? I'm talking in terms of exploit prevention. > > > Has anyone ever considered a model where the X server process forks Many times, in history it has been an exepted idea. Would you like to actualy code this? > > off another process for each remote user, and the that process listens > > on the remote net connection and makes X/GL/GLX calls just like a > > local process, forwarding GLX/X requests to the server process as > > needed? This may be the best model for the X on GL world. > > 1. Doesn't this mean we will have multiple process switches just to > process the traffic ? No, you close the handel in the parent process and release/logout on SIGCHILD. Connection 'back' the the X server could be done prefork so there is 'NO' chance of the process not being able to connect. > 2. How will such a model handle applications which render in the same > window but run under different UIDs ? > Why would [EMAIL PROTECTED] have a UID on host foo? For a local connection this whole thread dose not apply. > ---- > > Bye, > Roland > > -- > __ . . __ > (o.\ \/ /.o) [EMAIL PROTECTED] > \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer > /O /==\ O\ TEL +49 641 7950090 > (;O/ \/ \O;) > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > -- > _______________________________________________ > Dri-devel mailing list > Dri-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel > __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
