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

[Maxim Levitsky]

On Sunday, 6 January 2008 12:48:13 Barton C Massey wrote:
> 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!

Thanks too!
> 
> > 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.

Probably you are right. I wish glibc developers would use mmap() more often 
instead of that large brk() that only keeps growing.
I will use XCB, and maybe I try to hack it to use static pointers, and 
benchmark the results, anyway XCB is good, and I will use it.

> 
> 
> > (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.

Maybe I guessed a big too high figure, don't know. Today's GUIs take about 45 
MB of data, and similar amount of code (although the code is shared)

> 
> > 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.

Yes, I have thought about this, a single thread that gets all events, 
and wakes other ones,.. but what is wrong with making each thread have a 
separate connection, what are the disadvantages?

> 
> > (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
> 

Best regards,
	Maxim Levitsky