[Xcb] Hello xcblist.

[Jamey Sharp]

Hi Thomas! Last point first:

On Tue, Feb 9, 2010 at 12:02 AM, Thomas Heller
<thom.heller at googlemail.com> wrote:
> As a last point: My motivation for writing these bindings was to get
> in contact with X. I am currently not very experienced with all this
> stuff so the possibilities are very high that i totally missed
> everything important :)

The X Window System definitely needs more contributors. By all means,
don't let me stop you from exploring it any way you like. :-) I think
you've chosen a particularly difficult place to start, but hey, it's
where I started eight years ago, so I guess I'd be a hypocrite to stop
you. ;-)

To put that a more positive way, I think it's very important that people
explore new implementations of existing ideas, because otherwise we get
stuck and can't make progress. That's why XCB was worth doing: Xlib was
stuck. And I'm not so egotistical as to claim XCB is perfect---in fact I
have a number of complaints about it, and they're mostly my fault. :-)
So new research is absolutely welcome.

As these research prototypes begin to prove themselves, though, it's
also necessary to either fold the results back into the older
implementations, if possible, or to provide an easy migration path for
code written using the old design. XCB would never have been widely
adopted without our work to make Xlib compatible with it, and the same
is going to be true for anything trying to replace XCB.

> On Tue, Feb 9, 2010 at 6:37 AM, Jamey Sharp <jamey at minilop.net> wrote:
>> - Internally, we access buffers through pointers of different sizes
>> at different times. ...
>
> That is exactly what i meant. I am fully aware that this is the only
> way in C to handle such things.

Not the only way, just the simplest.

>> - Response types can't be distinguished at compile time, so we cast
>> once we've discovered the correct run-time type to use. ...
>
> Same as above. However I think i found a reasonable solution for this
> kind of problem.

Please share! I'd really like to hear about your solution. Perhaps
whatever approach you've come up with can be made to work in C as well,
and as I said, I'm always interested in better ways to do things.

> Yes that is more or less what i mean. However I doubt that the list
> implementation in the C++ standard library is less efficient than your
> implementation. Templates have no impact on runtime.

Templates clearly have an impact on code size, and code size can have an
impact on run time, due for example to cache effects. An implementation
that's more generic than needed can also have an impact on run time by
tracking values that will never be read, for instance. Finally,
abstraction can, in some cases, obscure the computational complexity of
your algorithms, leading to run time that is much worse than necessary.

I don't mean to say that C++ or templates or abstraction are bad for
these reasons---only that it's worth being aware of what they cost, so
you can decide when it's appropriate to use them.

> In my case: I have answered 1) with yes since there exists a library
> which takes care of asynchronous reads and writes to a socket in a
> very neat way, which i believe was the main effort behind libxcb.
> Correct me if i am wrong.

It's certainly true that one of the hardest things to get right in XCB
was supporting both single-threaded and multi-threaded programs
transparently, while ensuring that some thread is always willing to read
from the X server if any thread is trying to write to the X server,
which is a requirement of the protocol. I believe we re-wrote that bit
from scratch four times before Bart went off to design a
provably-correct algorithm and wrote the "X Meets Z" paper about it.
Even now I'm not entirely convinced we have it right, partly because I
was never quite able to implement Bart's algorithm. :-)

I looked over the asio library when I read your first e-mail. It does
look like a pretty nice abstraction. As far as I can tell, though, it
"solves" the above problem by requiring that at least one thread is
always running the io_service::run method, or an equivalent. That's a
design choice we weren't willing to make as it requires either threads
or the application's cooperation. Many applications already have their
own main loop, and trying to integrate two code bases that each want to
be the main loop is not easy.

And this isn't even the bulk of the code in XCB. It's actually a quite
small piece. XCB is mostly about quirks or details of the X protocol.
Which will be quite educational for you to work out, so again I can't
really argue against your plan. :-)

Jamey