display using unix-domain socket (was Re: fd passing for X)

Antoine Martin antoine at nagafix.co.uk
Sat Oct 6 09:16:51 PDT 2012

On 10/06/2012 10:42 PM, Michal Suchanek wrote:
> On 6 October 2012 12:32, Antoine Martin <antoine at nagafix.co.uk> wrote:
>> On 10/06/2012 05:15 PM, Michal Suchanek wrote:
>>> If the user is choosing a port or file path the user then needs to go
>>> through the dances of determining which port or path is still
>>> available for starting a new X server. This is just moved from the X
>>> server to user.
>> Important note: no ports are involved here, just paths.
>> There is a point in letting the X11 server do this allocation for TCP
>> ports (no changes here), which are in limited supply and need to be
>> allocated atomically, but none of this applies to unix domain sockets.
> Paths may be also in limited supply depending on acceptable paths.
See below.
One of the main benefits of being able to choose your own path, is that
you can be sure that it exists and that it is free. (but I am repeating

>>>> 2) That socket path can be totally private, using a file path with very
>>>> restrictive permissions if you wish to do so.
>>> That's definitely an advantage.
>>>>> As far as I understand the patch shifts the burden of finding a free
>>>>> port (or socket path) from the X server to the user.
>>>> Yes, it does. If by burden you mean freedom.
>>> You have to somehow determine if the path you picked is free or in use
>>> by earlier X server or another program.
>>> Think about two scripts trying to start an X server at the same time, etc.
>> ie:
>> SOCKET=`mktemp -d`/X11-socket
>> Not hard, is it? No parsing the output, no "go throught the dances of
>> determining which (..) path is still available..."
> Indeed, if you are fine with random nonsensical socket path then
> available sockets are unlimited.
Define "nonsensical". I'm fine with mktemp names for my use case for
example: in this context, it's not nonsensical at all, it's what you ask
The fact that it may seem "nonsensical" to others in this case is
actually a feature, not a bug.

Rather than using "nonsensical", I would much prefer using the terms
"user defined and potentially private", long but this makes it far less
of a loaded question.

> If you wanted some numbered sockets similar to what the X server uses
> now then the sockets have the same problem ports have. It's somewhat
> hard to find a X server you started previously and to associate random
> pieces of gibberish with multiple instances of running X server but
> lsof and inspecting the X sessions might help there.
I don't know what "random pieces of gibberish" you are thinking of,
please provide more concrete objections, these purely hypothetical use
cases do not seem very likely to me.

You seem to be arguing that if I choose to start a private server, using
a private socket, it cannot be found easily? Well, yes, and that is the
point really.

> Also some planning with picking only partially random socket names might help.
If you want to do that, you are welcome to, but I don't see what this
has to do with this patch.
If you write a piece of software that makes use of this patch *and*
somehow needs to cooperate with whatever else by making those sockets
public or shared, then by all means go ahead and do that.

Bad analogy: I don't see many pieces of software out there preventing
you from saving your documents in certain places "because you might not
remember what you did them". This is *nix. This patch does not change
any of the default behaviour, you have to explicitly use it.

Also note that adding this feature of "partially random socket"
(currently totally unused and imho with no valid uses cases), would
probably increase the level of complexity of this patch tenfold if not
more (it is only 3 lines after all).

It seems to me that you are trying to replicate the behaviour of TCP
sockets, because that's what's there, not because it makes technical sense.


> Thanks
> Michal
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel

More information about the xorg-devel mailing list