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

[Michal Suchanek]

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.

>
>>> 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.

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.

Also some planning with picking only partially random socket names might help.

Thanks

Michal