Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!slxsys!ibmpcug!ctssuk!acorn!john
From: john@acorn.co.uk (John Bowler)
Newsgroups: comp.windows.x
Subject: Re:  resource ID allocation
Message-ID: <5366@acorn.co.uk>
Date: 25 Feb 91 15:57:16 GMT
References: <9102140823.AA17984@lightning.McRCIM.McGill.EDU>
Organization: Acorn Computers Ltd, Cambridge, UK
Lines: 46

In article <9102140823.AA17984@lightning.McRCIM.McGill.EDU> mouse@lightning.mcrcim.mcgill.EDU writes:
>> If not, clients which manage a lot of resources for a long time may
>> run out of valid ID's.
>
>This seems like a silly thing to worry about.  However, suppose someone
>has some program running for weeks, creating and destroying windows,
>GCs, whatever, and then as it gets old, it crashes when its Xlib
>creates an invalid XID...unless Xlib does get this right, of course!
>(I haven't checked the source.)

Over christmas 1989 I ran Xvstress from the X Test Suite on (against :-))
one of our servers.  When I came back (after about two weeks) the
XVSpixmap test had failed with a BADIDChoice error.  This test creates
two pixmaps from bitmap data, sets a window background to one of the
pixmaps, clears the window and frees both pixmaps.  This was running
in parallel with the other 16 or so tests, and the server had the
``normal'' number of client bits (ie 20).  OK, this is a stress test,
but it still seems entirely believable that some serious, long lived,
applications will end up creating and freeing that number of resources
over a long time period.

I fixed up XVSpixmap.c by remembering display->resource_id before the
test and resinstating it after (when the pixmaps had been freed). 
Although this is a hack which depends on knowledge of how the default
display->resource_alloc works (display->resource_id++ :-)) the basic
approach could be used in an application which knows that resource
id's used in a particular sequence of operations will (all) have been
freed at the end of that sequence.

Detecting wrap-round is easy, but dealing with it is not.  In general
a (probably) small number of resource id's will be permanently allocated
as an application starts up; it is essential that no attempt is made to
reuse these when the resource id counter wraps round!  There are obvious
heuristics (wrap round to client_base+<small number> rather than client_base),
but the application may also allocated permanent id's at arbitrary times
while it is running...

The general solution is to have a private display->resource_alloc
procedure which ``knows'' whether an id is only required for a short
time or for a long time.  It can then maintain two counts, and use one
for ``permanent'' allocations and the other (which will probably wrap
round) for ``temporary'' ones.  A possible implementation is for the
caller of an Xlib routine to set a ``permanent_resource_id_required''
global flag before making a permanent allocation and reset it afterwards.

John Bowler (jbowler@acorn.co.uk)