[Xcb] Getting time since server started and `XIfEvent'

Jamey Sharp jamey at minilop.net
Tue Aug 9 06:03:03 EST 2005

On Sun, 2005-08-07 at 11:09 -0700, Travis Spencer wrote:
> Hey All,

Hi Travis!

I've spent the last six hours trying to reply to your e-mail, and it's
making my head hurt. So I'm sending the easy answers first, and later
I'll try to figure out what else I'm trying to say.

> I'm porting a function [1] called get_server_time that gets the number
> of milliseconds since the X server started.

I don't believe it's actually specified anywhere that X timestamps are
"milliseconds since server started" -- I think they're only expected to
be monotonically increasing over time. Which of course has nothing to do
with your question. :-)

> I think I've got it, but
> I would really appreciate it if someone could double check my work. 
> My test app is currently at
> http://www.travisspencer.com/stash2/tests/ctests/servertime.c.

There are some tricky things going on here. A couple of comments on this

When using both Xlib and XCB on the same connection, only one library
can own the event queue. By default it's Xlib. If you access XCB's event
queue when Xlib owns it, the results are entirely uncertain; and you may
mis-process some events if you switch ownership after events start
arriving. (Events cannot be put back into XCB's event queue.) Your
servertime.c test app will probably run fine since you don't make any
Xlib calls between calling XCBChangeProperty and XCBWaitEvent, but in
general you need to use this function from xcl.h:

enum XEventQueueOwner { XlibOwnsEventQueue = 0, XCBOwnsEventQueue };
void XSetEventQueueOwner(Display *dpy, enum XEventQueueOwner owner);

Also, the XCBSync isn't necessary since you're using XCBWaitEvent: an
XCBFlush should be sufficient. Actually I'm very confused now because it
seems like XCBWaitEvent should flush if no events are in the queue, but
it doesn't. I'm sitting here trying to figure out the performance
implications of always writing whenever we're waiting to read something
and select says we can write: it seems like it should be OK.

Anyway, there's a small bug in servertime.c:
        if (e->response_type & 0x7f)
should check that response_type actually equals XCBPropertyNotify after

> The thing that I am especially unsure about is the port of XIfEvent in
> the function get_server_time_xcb.  I replaced that function with a
> call to XCBSync and a loop that processes all of the events.  If I'm
> not mistaken, XIfEvent leaves all events in the queue except the one
> for which the predicate returns true.  My port, however, is removing
> all events including the one that is being sought after.

Yes, you haven't ported it exactly. As you say, you're only supposed to
remove the event that matched.

What to do instead? Six hours on that question and counting... I'll get
back to you.

> I know it is a lot of code to look through, but I would really
> appreciate the feedback.

I was going to reply that there wasn't actually much code to look
through, until I found myself reading large swaths of the Gdk source.

> If it looks good or after it does, I'll write up a little blurb about
> it and add it to the porting guide that I'm working on.

Great! I wonder how "little" the blurb will turn out to be
though...? :-)


More information about the xcb mailing list