[RFC] Making tracing/debugging of client requests easier
Rami Ylimäki
rami.ylimaki at vincit.fi
Fri Jul 2 03:51:31 PDT 2010
On 06/16/2010 05:50 PM, ext Alan Coopersmith wrote:
> Rami Ylimäki wrote:
>> 3. Collecting client information in X server
>>
>> Whenever a client connects to X server, its PID and process name (for
>> local clients) would be determined by the functions described in
>> previous section and stored in a private data structure. This would
>> make it easy to quickly determine a sensible name for any connected
>> client for debugging purposes. Also having a map from client XIDs to
>> PIDs would make implementation of the new XRES query described in
>> first section fast.
> The Xorg shipped in Solaris/OpenSolaris already does this as part of
> the SolarisIA extension, which gives a kernel scheduler priority boost
> to the client that has window manager focus. It's on the list of things
> I know I should work on getting upstream someday, but have never gotten
> to, but you can see the fairly simple code on the opensolaris site at:
>
> http://src.opensolaris.org/source/xref/x-cons/xnv-clone/open-src/xserver/xorg/sun-src/IA/interactive.c
>
> It keeps track of multiple PIDs per client, so that your terminal can
> register the shell its running to also be boosted, or other related
> processes.
>
> Certainly if we're going to have multiple things doing this, a generic
> framework makes sense.
Thanks for your comments, I'll get back to this subject after my
vacation somewhere in August. I've been a little busy with other things
after posting the RFC so I haven't yet looked at your code much.
>> Some existing clients using XRES are iterating window hierarchy and
>> searching for _NET_WM_PID, but that approach is too slow and
>> unreliable for finding out client PIDs. At least the xres and cnee
>> clients would be able take advantage of this new request and make it
>> easier to identify local clients.
> I've wondered before if it would be sensible to have either Xlib or the
> server set the _NET_WM_PID automatically for new clients. Clients could
> always override it later (and any client that already has code to set it
> would effectively do so, since their setting would come after the initial
> connection setup). That doesn't solve the problem of having to walk the
> window tree to find it though.
I think we want to avoid walking the window tree. It may even be that we
want to trace some client that doesn't create any windows.
One thing that I was wondering when investigating this is that why are
properties restricted to windows? However, the properties seem to be
implemented in a different manner for different objects in extensions
like XV (port attributes) and XI2 (device properties).
So I guess that based on your comment it would be best to make XRES
similar to the other extensions and provide means to set and get client
properties. In that case we wouldn't use _NET_WM_PID window property but
would just make it possible to attach some extra data identified by an
atom to client structures. By default we would then set some
_LOCAL_CLIENT_PID for the client XID and wouldn't need separate requests
for querying extra data that we might want to attach to clients in the
future.
-- Rami
More information about the xorg-devel
mailing list