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

[Antoine Martin]

On 10/07/2012 07:06 PM, Michal Suchanek wrote:
> On 6 October 2012 18:16, Antoine Martin <antoine at nagafix.co.uk> wrote:
>> 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
>> myself)
>>
>>>>>> 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
>> for.
>> 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).
>>
> 
> no, it only requires a better example.
> 
> $ SOCKET=`mktemp -d`/X11-socket
> $ echo $SOCKET
> /tmp/tmp.Ooa6YzzSfJ/X11-socket
> $ SOCKET=`mktemp -d`/X11-socket
> $ echo $SOCKET
> /tmp/tmp.Ery2iRjLqt/X11-socket
> 
> Now you have two totally nonsensical socket names and you can't tell
> which one is the first and which one is the second X server. Note that
> they are actually reversed alphabetically.
You're still using the inappropriate term "nonsensical" to build up your
straw man argument, so one more time: if you chose a random name, you
get a random name. And you should call it "random".
Don't want it? Don't use it.
Or maybe you have an app that wants to do something clever with this?
Then please share. Until then... this is as relevant as unicorns.

> If you used SOCKET=`mktemp -d`/X11-socket-0 and then increased the
> number you would have an identification of X servers created by the
> same application but X servers created by different applications or
> stale sockets would still mix together. Anyway, if that's what you ask
> for it's probably fine if you get that. I just would not be enormously
> excited about any application using this feature to spawn Xvfb or
> whatever as opposed to grabbing first free display number in the
> current scheme.
This is a very contrived example: you purposedly create two sockets as
the same user, in the same directory, with random names, then complain
that you don't know which is which, err, sigh. Don't do that then!
You should probably file a bug with every application that allows the
user to choose the target location, because that can be "confusing" too.

Antoine

> 
> Thanks
> 
> Michal
>