Re: The meaning(s) of $DISPLAY (was Re: Explanation of X implementations)
Re: The meaning(s) of $DISPLAY (was Re: Explanation of X implementations)
- Subject: Re: The meaning(s) of $DISPLAY (was Re: Explanation of X implementations)
- From: Derek Fawcus <email@hidden>
- Date: Mon, 19 Nov 2007 12:05:07 +0000
On Sun, Nov 18, 2007 at 04:38:41PM -0800, Ben Byer wrote:
> On Nov 18, 2007, at 3:56 PM, Derek Fawcus wrote:
>
> > Well I consider the redefined contents of DISPLAY to be rather an ugly hack.
>
> Bummer. Why?
(Well I did write 'I consider', rather than 'It is' :-).
Basically because of the knock on effects, which I view as unnecessary if the
slight variation I described was chosen. A new DISPLAY format only needed to be
defined because the chosen approached added a new socket, but the new socket
provides nothing that could not be achieved with the existing socket.
One could argue about the knock one effects, i.e. that other programs should
not be parsing DISPLAY outwith of the X trans library, but they are. So now
there are patches for ssh to handle the new DISPLAY format, and similarly
patches to xauth.
I _think_ it could all have been hidden within the trans library without any
need for a new type/name of socket, and so no externally visible change.
At worst it would have been specialised code in the Xserver, and something wrt
launchd (i.e. does one just hardcode the "/tmp/.X11-unix/:%d" pattern in
to it, or try to use some form of helper / decoupling?).
I'd certainly be willing to hack up how I think it should be done, but then
I'm still on tiger. (I need to get the server compiling anyway), I _believe_
the launchd source is public?
> > It should be possible for launchd to listen on the normal :0.0 (/tmp/.X11-unix/:0)
> > for a connection, then when that socket can accept without blocking, spawn an
> > xserver and pass the listening socket to it. Launchd never calling accept on
> > the socket. Then if/when the xserver dies, launchd goes back to waiting for
> > the listening socket to be able to accept without blocking.
>
> I believe that's what it does, currently (with the exception of the
> part I highlighted in red).
Red? </fx manually parses html>the path?</fx>
OK - so if it passes the listening socket (rather than the fd returned from the
accept call), there is no need to have a new path. Therefore no need to change
the contents of DISPLAY. Also it seems that there should be a chance for the
server to initialise before it does the accept and builds state for the first
client.
[snip]
> > The first scheme seems as if it may be easier to hack in to the xserver xtransport
> > stuff, as the server would have a chance to do its xinit stuff before it called
> > accept (i.e. it acts as if it was started before the first connections occurred).
>
> Wait, which problem are you trying to solve, here? The xinit race
> condition, the changes required to support the new $DISPLAY naming
> scheme, ?
Both :-) But primarily the name issue.
However I was assuming that the xinit race was a consequence of the changes to
handle passing the socket, and that it was because the per client socket was
accepted in launchd and passed, then recorded early in the trans related code,
rather than allow the trans code to simply do its own thing based on passing
the listening socket fd. (This is pure speculation on my behalf).
It could well be that this is a long term issue with the serverr code, and it has
always had that race. I guess that should be easily testable using Xnest...
DF
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden