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

[Jamey Sharp]

On Mon, 2002-07-08 at 14:07, Andy Howe wrote:
> I'm leaning the same way as you are. I think in the case of events,
> doing it this way has advantages. It allows you to return an integer
> from the function so you can check for errors easier.

Error handling is certainly an interesting case, and XCB doesn't do it
well yet.

> The problem comes with
> XCBPollEvent(). XCBPollEvent() returns 0 if there is currently no event
> on the queue. If we were able to return an integer from XCBPollEvent(),
> we would be able to, for example, return 0 if no events are in the
> queue, 1 if there are more events in the queue, and -1 if there was an
> error. 

I don't feel bad about failing to distinguish between "error" and
"nothing to do". All that the caller really needs to know is that no
event could be returned; I argue that the underlying cause isn't
important.

But I would happily listen to arguments to the contrary.

> I was also considering an XCBPeekEvent() function, that looked for an
> evet of a certain type on the queue, and returned that event, but didn't
> remove it from the queue. This function would have similiar return
> values to XCBPollEvent(), since it might return a 0 pointer even if
> there was no error.

Already done; it's called XCBEventQueueFind, and it is declared in
xcb_event.h. Its partner, XCBEventQueueRemove, allows the caller to
remove the event that is found while returning it. I needed the Remove
variant for XCL, since Xlib has a variety of predicated event retrieval
functions; and the Find variant was trivial to build on my generic
linked list implementation, since I needed similar functionality for
handling the list of pending replies.
-- 
Jamey Sharp <jamey@sharp.ath.cx> - http://jamey.is.dreaming.org/