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
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
