asked upstream about it. The patches are indeed in RHEL4, so they should be tested by now. They don't seem to qualify as-is to upstream though:
20:52 < ajax> you trade more clients for fewer resources per client
21:05 < ajax> the XID space is carved up weird
21:06 < ajax> (when i say "resources" i mean "protocol objects with an XID")
21:06 < ajax> top three bits are reserved (f*** you lisp), next eight bits are client id, the
rest are for the client to allocate however it likes.
21:08 < ajax> so, with 256 clients, each of them can create up to 2 ^ (32 - 8 - 3) ~= 2 million resources
21:08 < ajax> 512 clients, one million resources each. etc.
21:09 < ajax> XIDs are allocated client-side to avoid round-tripping to the server on every resource creation, but that means you have to be able to allocate unique ids within each client. so you have to have some partition...
21:10 < ajax> i suppose the right way to fix this is to do a field survey of how many resources a typical "small" app and a typical "big" app use.
21:13 < ajax> on my machine, metacity is far and away the one with the most resources, and
it's still down around the 2000 mark
21:13 < ajax> you do still want a fairly sizable allocation per client since XID reuse is pretty fast and furious, and requires a round trip through xc-misc
21:14 < ajax> and, you can't know that you're talking to an xlib that's new enough to know
about the newer version of xc-misc
21:18 < ajax> this _might_ be a case where you could do protocol 11.1 meaningfully
21:18 < ajax> which would let the server assign huge ranges to 11.0 clients and tiny ones to
11.0 clients
21:18 < ajax> uh, tiny ones to 11.1 clients
so, we can fix this in our packages, but it would not be the final solution.
asked upstream about it. The patches are indeed in RHEL4, so they should be tested by now. They don't seem to qualify as-is to upstream though:
20:52 < ajax> you trade more clients for fewer resources per client
million resources
resource creation, but that means you have to be able to allocate unique ids
within each client. so you have to have some partition...
resources a typical "small" app and a typical "big" app use.
pretty fast and furious, and requires a round trip through xc-misc
21:05 < ajax> the XID space is carved up weird
21:06 < ajax> (when i say "resources" i mean "protocol objects with an XID")
21:06 < ajax> top three bits are reserved (f*** you lisp), next eight bits are client id, the
rest are for the client to allocate however it likes.
21:08 < ajax> so, with 256 clients, each of them can create up to 2 ^ (32 - 8 - 3) ~= 2
21:08 < ajax> 512 clients, one million resources each. etc.
21:09 < ajax> XIDs are allocated client-side to avoid round-tripping to the server on every
21:10 < ajax> i suppose the right way to fix this is to do a field survey of how many
21:13 < ajax> on my machine, metacity is far and away the one with the most resources, and
it's still down around the 2000 mark
21:13 < ajax> you do still want a fairly sizable allocation per client since XID reuse is
21:14 < ajax> and, you can't know that you're talking to an xlib that's new enough to know
about the newer version of xc-misc
21:18 < ajax> this _might_ be a case where you could do protocol 11.1 meaningfully
21:18 < ajax> which would let the server assign huge ranges to 11.0 clients and tiny ones to
11.0 clients
21:18 < ajax> uh, tiny ones to 11.1 clients
so, we can fix this in our packages, but it would not be the final solution.