Fixing devPrivates

[Tomas Carnecky]

On 4/29/10 8:59 AM, Keith Packard wrote:
> Most of this should be fairly obvious, the one exception is probably the
> 'type' value. This is a fixed enumeration of all possible data
> structures holding devPrivates. Let me make that a bit louder.
>
> I AM PROPOSING TO ELIMINATE THE ABILITY TO USE THE DEV PRIVATES
> INFRASTRUCTURE IN DATA TYPES DEFINED OUTSIDE THE CORE SERVER.

Almost two years ago I started looking into this very same issue (and 
even wrote some code). My idea was the DevPrivate key to become a simple 
offset into an array, much like your approach. However, I allowed keys 
to be registered even after the first object had been created. And I 
even had an API to register new object types (unlike your fixed 
DevPrivateType enum).

My DevPrivateRec was basically a structure with 'int size; void *ptr', 
and PrivateSet/Get functions would check if the ptr size was big enough 
and realloc() it if needed. The only disadvantage I see in that is the 
overhead of an occasional realloc(). Is there any other reason you chose 
to allocated the array only once when the object is created?

Another difference, albeit a minor one, was that I kept my 
'DevPrivateRec' structures allocated inside privates.c instead of 
scattered around the source files. That allowed me to easily dump 
statistics about which privates are used in which objects etc. I thought 
that would be a useful feature for debugging purposes, or to simply see 
how much memory is being used where.

tom