[Xcb] [RFC] XCB without use of malloc()

[Barton C Massey]

In message <200801061222.01158.maximlevitsky at gmail.com> you wrote:
> I need to choose what library to use Xlib or XCB.
> I like XCB, since it is small, simple, and has nice coding
> style.

Thanks!

> But I have one problem with XCB, I think that it uses
> malloc() too often.  It isn't question of speed, I know
> malloc() is quite fast, and used today by all languages
> very often.  But calling malloc over and over again
> fragments memory, thus I want to avoid using it heavily.

> For example in the event loop I want to allocate fixed
> buffer for incoming events, and use it over and over
> instead of mallocing and freeing it.

> So how about that, how about adding an option for
> reply-receiving functions to get a pointer to already
> allocated data, (at least to a subset of functions).

The problem is that XCB has a very asynchronous
thread-transparent design.  Typically, the reply data has
already been saved in user space long before the
reply-receiving function is called, so it's too late to
supply a pointer then.

If you're really that concerned about memory fragmentation,
you could hack up the XCB code generator for yourself to
create variants that took a pointer to the reply data in the
request-generating function, and then hack up the XCB lower
layer to use these pointers.  This sounds like a lot of
work, though, and IMHO it is unlikely to save you a
measurable amount of performance.


> (My goal is to create a very memory efficient tookit, to
> fit whole large GUI in few MBs, so I don't want to waste
> heap on fragmentation).

This shouldn't be even a minor concern.  In a megabyte of
pool, any decent malloc implementation will do a great job
of packing the tiny allocations that come with typical
replies and events.

> On the other hand XLib doesn't have this feature, but I
> have seen that it has problems with threads, so I don't
> like to use it.

> Speaking of threads, how do you deal with them?

> I am thinking that each thread should open a separate
> connection to X server, and thus it will get its own
> events in its own private message loop.  Is this a
> good/working design?

XCB goes to a ton of trouble to be thread-transparent;
there's no need to open separate connections. You may need
an extra dispatch thread to route events to their
appropriate consumer thread, but you're going to need to
figure out event dispatch anyhow.

> (And I am thinking that at least theoretically it is
> possible to do in XLib too, with help of XInitThreads)

That's one of the only ways you can do it reliably in Xlib.

     Bart