XTS repo - where to?

[Peter Hutterer]

Adding xcb list, I _think_ this is an xcb issue.

On Tue, Jun 29, 2010 at 05:39:41AM -0700, Dan Nicholson wrote:
> On Tue, Jun 29, 2010 at 4:07 AM, Daniel Stone <daniel at fooishbar.org> wrote:
> > On Tue, Jun 29, 2010 at 04:11:04PM +1000, Peter Hutterer wrote:
> >> XTS still lives in dan's, aaron's and my $HOME on annarchy.  Which is not
> >> ideal, for obvious reasons. We've had this discussion on IRC a few times,
> >> with my current preferences being either
> >>     /git/xorg/xts
> >> or
> >>     /git/xorg/tests/xts
> >>
> >> The second optimistically thinking that over time we may accumulate more
> >> tests that need to go in there. Do we have any, or in the near future will
> >> we see any? If not, then I'd opt for the first one.
> >
> > I've set up /git/xorg/test/xts, per Tiago & Mikhail's comments, and
> > noting that the other dirs are called lib instead of libs, app instead
> > of apps, et al.
> >
> > Cheers,
> > Daniel
> >
> > PS: You own XTS.  Ha!
> 
> Peter, I've got your branch you sent me plus a bunch of local fixes. I
> just pushed it to ~dbn/xts.git master.
> 
> One thing that happened is that your DISPLAY fixes corrected a bug
> where tests forking themselves now properly try to open the correct
> display instead of bailing out because DISPLAY isn't set. This was
> making Xlib3/XConnectionNumber hang in XFlush on me yesterday. Can you
> have a look at that one? I can't figure out what would make that
> happen.

Looks like this may be some rather weird behaviour xcb doesn't cater for.

closer() in xts5/Xlib3/XConnectionNumber.c calls close(2) on the display's
fd. Then it calls XFlush(3).
http://cgit.freedesktop.org/xorg/test/xts/tree/xts5/Xlib3/XConnectionNumber.m#n128

XFlush(3) eventually calls _xcb_out_send() with has the following loop:
    while(ret && *count)
            ret = _xcb_conn_wait(c, &c->out.cond, vector, count);

_xcb_conn_wait(), if built with USE_POLL gets the POLLNVAL error. It only
checks for POLLIN and POLLOUT though, ignoring the error.
Return value is 1, count is unmodified, leaving us with an endless loop and
the hang you noticed.

Now you could argue that closing the file descriptor on xcb is nasty but I
think xcb should probably cater for this eventuality. Am I reading this
right?

Cheers,
  Peter