[xcb] Memory management in XCB (was: XCB polling and single-threadedness)

[Jamey Sharp]

On Mon, 2002-07-08 at 11:49, Carl Worth wrote:
> On Jul 6, Andy Howe wrote:
>  > You just need to free() the event returned by
>  > XCBWaitEvent()/XCBPollEvent(). As an example, Hypnomoire does this in
>  > event_thread().
> 
> Lack of automatic memory management should be on everyones' list of
> Top 10 Reasons to Hate to Love C.

Or at least "Reasons C Isn't Quite As Cool As Everyone Thinks It Is."
But as long as you're aware of why you're using C, I don't see that it's
a problem. The real problem is when people use C for a task better done
in Java, ML, Haskell, Nickle, etc.

> In order to deal with the inherent ambiguity when a function returns a
> pointer, (to free or not to free?), I've been leaning toward following
> the following stylistic conventions in most of my code:

As far as I'm concerned, XCB doesn't have this ambiguity. If it returns
a pointer, it's the caller's responsibility to free it.

I'll grant that XCBConnect et. al. don't quite follow this, though;
XCBConnection is the only structure I can think of in XCB that has
pointers. For this reason, it does need an XCBDisconnect, and it's only
my laziness that has kept such a function out of XCB so far.

There is one other exception: XCBQueryExtensionCached. This function
returns the requested item directly out of the cache. Following a style
tip I read somewhere, I tagged the return value "const" to indicate that
it should not be freed. (I also commented this aspect of the function's
contract.)

> So, looking at the case in hand, I would vote for following (1) and
> having XCBWaitEvent and XCBPollEvent fill in an XCBGenericEvent passed
> in to the function. Of course, this is similar to what Xlib does.

I guess this works for events, because Keith or somebody was quite
insistent in telling me that events are always 32 bytes long. I could
have sworn I saw a longer event in some extension, though.

However, the application in general has no way of knowing how much
memory to allocate for replies. For this reason, I think the memory for
replies must be allocated inside XCB, and a pointer to it returned.

In any case, it would significantly complicate the internals of XCB if
it had to wait for the caller to ask for a response in order to get
memory in which to put that response. I suspect it would roughly double
XCB's memory consumption and time spent copying, in fact. I can't see
any way that this is a good thing.

Any arguments to the contrary? :)
-- 
Jamey Sharp <jamey@sharp.ath.cx> - http://jamey.is.dreaming.org/