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

[Thiago Macieira]

On Sunday, 21 de August de 2011 10:19:26 Oswald Buddenhagen wrote:
> > What instability? If kded crashes, what makes you think individual
> > services
> > won't crash, in addition to taking longer to load and use more memory?
> 
> look at it from the perspective of the daemon, not the modules.
> there have been *tons* of bugs related to crashes and freezes in
> kded - which were module bugs actually.
> in-process is simply no sound architecture from a stability (and
> security) pov. guess which other kde component i'm thinking of ...

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.

In any case, kded restarts.

> > if we start from an all-privileged daemon like systemd. It's privilege
> > elevation that suffers.
> 
> does the session systemd run privileged in the first place?

I have no clue. I don't even know if there's a session systemd.

> > It's far easier to introduce the feature we want into the prelinker and
> > dynamic loader, such as having a "stasis" process: the dynamic loader
> > could
> > load everything as needed, then freeze the images just prior to running
> > any
> > code.
> 
> one can have that with some ptrace trickery.
> but i'm not sure how this fixes the problem. do you want to exec() such
> pre-initialized images?

This isn't a fully-formed idea. It might need kernel help too.

> > > i think it is pretty clear that our *code* is not going to be accepted
> > > as the cross-desktop solution. [...]
> > 
> > I don't know where you got those numbers for weight, not to mention it's
> > completely ambiguous (did you mean memory consumption?).
> 
> code size => shared memory, page faults on load.

That is true. But it is not proven. Sure, QtCore is much bigger than glib:

$ ls -l /usr/lib/libQtCore.so.4.8.0 /lib/libglib-2.0.so.0.2800.8 
-rwxr-xr-x 1 root root  979028 Jun  8 02:53 /lib/libglib-2.0.so.0.2800.8*
-rwxr-xr-x 1 root root 2980096 Jul 25 22:28 /usr/lib/libQtCore.so.4.8.0*

But file sizes don't mean much. You'd have to check how much in page faults 
really happens to fault in those services: given comparable uses of the 
libraries, what is the actual memory use? What's more, you can also justify it 
as a trade-off in readability and maintainabilty.

In a running system, where QtCore is already loaded, there aren't any page 
faults to load the code or marginal increase in memory usage because of it. 
And if we fix the above problem of prelinking, the prelinked read-only data can 
also be shared.

(note my use of commas in "where QtCore is already loaded": it's not a 
restrictive definition of system, it's an explanation of it; for me, there are 
no systems where QtCore isn't already loaded)

> - introducing a qt or even kde dependency into a so far gnome-only
>   system can be a very real resource problem. that's not likely to apply
>   to kglobalaccel (as it is pretty desktop-specific), but i'm assuming
>   you are making a general statement

Right. And if we accept glib dependencies, I don't see why they shouldn't 
accept QtCore dependencies.

> > I could even accept the alternate representation to be optional, so an
> > UTF-8- to-UTF-16 coversion needs to happen when Qt-based code reads
> > the config.
> 
> on-demand conversion could lead to some nasty encoding ping-pong when
> the data is accessed concurrently.

You misunderstand dconf: 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 don't see a ping-pong.

> > The problem I found is the same as QUrl today: implicit sharing of lazily
> > constructed data. When you need to finish your lazy work, do you need to
> > detach or not? If you detach, only one side will get the non-lazy output.
> > If you don't detach, you need to somehow make the setting thread-safe --
> > which QUrl doesn't do.
> 
> not detaching needs to do atomic pointer replacement to avoid memory
> leaks, but other than that it is relatively uncritical.
> a problem is of course that the converted data would need a separate
> allocation, as opposed to the embedded raw string data.

If you don't detach and you do replace the pointers, when do you delete the 
old data? You need a shared data pointer of some kind. I don't want to 
introduce a second reference count in QStringData.

> 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, so
> checking the need for detaching and conversions would have to be done
> only when obtaining the reference.

That's QCharRef.

> but that was long before qt5 actually materialized, including its
> "mostly source compatible" mandate.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110821/3c198877/attachment.sig>