GetXID{List,Range} start from 0
First go read xorg/lib/libxcb#51, then when you're finished drinking yourself blind check out how xserver makes it worse.
The problem described is {bless,curs}edly rare to encounter because the offending XID is going to be at or near the end of an available range. If your client is creating/destroying enough resources that you need to invoke XC-MISC then it's likely that the resource with the offending XID is itself going to be one that gets destroyed before the reuse gets noticed. At least, the first time through the client's XID space, this would be true. But the second range you get, the one from the GetXIDRange
request, is computed starting at the low end of the client's XID space, and this is true of every call to GetXIDRange
. Which means successive calls are likely to be scavenging over the same (slowly filled) holes in the low ends of the client's XID space, and thus you're likely to hit the BadIDChoice
case much more often.
The server could make this slightly better by keeping a "last recycled XID" cursor field in the ClientResourceRec
so subsequent GetXIDRange
calls would start just past where the previous one left off. This would probably also increase performance in the general case, since if the holes in the low end of the range fill up you would spend less time grinding through them again on each round-trip, and also (probably) returning larger ranges on each query so eliminating round trips.