[Xcb] xlibs --with-xcb unbroken

[Jamey Sharp]

On Sat, Feb 12, 2005 at 11:26:47AM +0100, Bernardo Innocenti wrote:
> Jamey Sharp wrote:
> >Those *are* malloc'ed structures. I wouldn't be at all shocked if the
> >condition variables frequently have results from previous read()s in
> >their padding bytes.
> 
> You're right for the padding stuff, but the lock isn't
> actually initialized.
> 
> I've gone back to the place where that XCBReplyData structure
> is allocated, and it's corrupted right from the start, even
> tough there's actually a call to pthread_cond_init().
> 
> It seems pthread_cond_init() is a no-op.  I wrote a one-liner
> test and it works the same, until I build with -pthread.
> 
> I didn't know: glibc exports a dummy pthread_cond_init
> weak symbol that gets overridden by libpthread.

Oh, right. Yes, we depend on that feature in XCB.

This means that we just write all XCB internals with correct locking,
but get very little performance hit in non-threaded apps. One of our
design goals was to provide the same API regardless of whether the
application was single- or multi-threaded, and this is one piece that
enables that. (There are larger difficulties in meeting this design
goal: see the "X meets Z" paper that Bart wrote for more.)

> That's silly, it means that even if you build single-threaded
> programs, your code still jumps into pthread stubs -> almost
> the same overhead.

I can say with certainty that's not true. I did some timing tests of a
trivial XCB-based single-threaded app, both linked with -lpthread and
without. The version linked with -lpthread took longer to run. (I don't
have the numbers handy, unfortunately.)

This isn't the 1980s any more. Function calls are cheap.

> >ListFontsWithInfo generates one X reply for every font on the system. I
> >would expect that you'd see a result like the above for the first of
> >those replies (and that would work fine), but the subsequent replies
> >would lose. Is that different from what you're seeing?
> 
> Yes, the second time, rep->data still points to old data
> and the assertion fails.

Ah, right. I think if the input queue length were reduced to 32 bytes
or so you'd get different behavior, but it still wouldn't be what you
wanted. ... Might make the assert go away, and cause all the following
replies to that request to produce "Unexpected reply" warnings on
stderr.

Well, anyway. It needs to be fixed the right way, sooner or later.

--Jamey