kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)

[Oswald Buddenhagen]

On Sun, Aug 21, 2011 at 11:28:02AM +0200, Thiago Macieira wrote:
> Sure, if each of 10 modules has a certain chance of failure or MTBF, the whole 
> process has a much greater chance of failure or smaller MTBF. But if you look 
> from the point of view from the system that requires each of those services, 
> it doesn't matter if the crash brings down all services or just one.
> 
not all kded services are required - many are more like "recommended".
but even if we assume that all are required, then out-of-process still
improves fault isolation and recoverability.

> In any case, kded restarts.
> 
yes, when the faulty module crashes. not so when it deadlocks or
busy-loops. also, a restart typically loses state.

> > code size => shared memory, page faults on load.
> 
> That is true. But it is not proven. [...]
>
well, yeah, somebody has to do some real research. but the outcome is
pretty predictable: qt's use of templates makes it extremely likely that
significantly more code is executed, and the rather likely suboptimal
code locality makes it probable that more unused code needs to be paged
in from the much larger binary.

> What's more, you can also justify it as a trade-off in readability and
> maintainabilty.
> 
well, of course. but given the availability of two equivalent solutions
and people willing to maintain them, the one with a lower resource
consuption will always be favorable.

> Right. And if we accept glib dependencies, I don't see why they shouldn't 
> accept QtCore dependencies.
> 
well, given that glib is an accepted dependency of qt (at least on the
desktop), qt will always be an *additional* dependency. it's going to be
interesting to push it down the stack enough that people stop thinking
about it.

> reading settings is done via mmap()ed read-only memory. If the UTF-16
> encoding isn't there, then the reader needs to create a QString from
> the UTF-8 data.
> 
> Writing is done via D-Bus.
> 
i know. exactly this has the potential for ping-pong if you do on-demand
conversion of the actual store.

anyway, i really wonder whether insisting on utf-16 makes sense, assuming
that the store is not abused for more than config data. KConfig and
QSettings use utf-8, too, and nobody seriously complained about that
afaik. the dconf client can implement caching of converted data just
like the exising classes do.

> If you don't detach and you do replace the pointers, when do you
> delete the old data?
> 
the lifetime would be bound to the qstringdata, like the latin1 data in
qt3-. i wouldn't bother with sharing the converted values - upon
detaching, the format which is needed for the operation which caused the
detach is made the primary (embedded) and only data of the clone.

> > when i was pondering this with andre, we came up with the idea to make
> > character access possible only through some kind of reference object,
> 
> That's QCharRef.
> 
more like a qstringref, as we want bounds checking. but it should be
also possible to append to the non-const variant of that thingie.