[Portland] Project Portland, RuDI and the Generic desktop adapter
nf2 at scheinwelt.at
Thu Dec 8 23:34:31 EET 2005
Lubos Lunak wrote:
>On Wednesday 07 December 2005 13:00, nf2 wrote:
>>Perhaps you can give me some feedback on my proposal and tell me if it
>>makes sense to continue working in that direction.
>>What do you think?
> Let me comment on some of the things from the page:
>>RuDI - but it would require IPC plus daemons. IMHO using IPC would just be
>>workaround for not fixing the mainloop thing, causing complexity and costs
>>in performance/memory which seem not reasonable here.
> Just to give you something to compare these costs to, doing a dlopen of the
>KDE library that provides the KDE file dialog takes about 0,4-0,5s on a
>900MHz machine and causes somewhere between 0,5 and 1 MiB of unshared (i.e.
>per-process) memory (I can't find out the memory usage exactly because 2.6
>kernels apparently can't give a number of dirty pages for a process). That's
>all caused just by the dynamic linker. The time issue could be fixed e.g. by
>Michael Meek's -Bdirect, the memory usage can be probably avoided only by
>non-trivial improvements in prelink.
But this won't differ from running ordinary KDE applications. With my
desktop adapter prototype i didn't recognize any extraordinary delay
when opening KDE file dialogs.
What i meant with performance/memory cost of an out-of-process approach is:
* requiring daemon process(es). perhaps multithreaded or one per
application. (designing and dealing with them will be quite a challange)
* marshalling + buffers
* context switching
>>Just an example: Providing filedialogs means that applications also need
>>access to VFS ("network transparency") libraries for downloading and
>>uploading files. Streaming file-data with SOAP, D-BUS or any similar socket
>>protocol is a performance nightmare.
> Actually KDE's KIO uses IPC (plain unix domain socket) for communication
>between the kioslave and the application. I don't remember anybody
>complaining about it. Also, things like filedialogs are actually not that
>performance demanding, as far as the application<->dialog communication is
I know that KIO-slaves use a socket protocol. But it's lean and fast,
because it has been designed for one particular purpose.
Wrapping a high-level IPC protocol around something like the KIO-Jobs
API will be extremely tricky. I reckon you can't just use DBUS messages
as usual. Plus file-data has to cross another IPC bridge (more context
> As for complexity, I think it's not so clear whether IPC increases or
>actually decreases the complexity. If you use another process, you have a
>very clear separation, if you do everything in-process, you have several
>codebases that must coexist nicely.
Coexistence problems are very interesting and should be analyzed and
sorted out anyway (for things like GParts/cross desktop components). But
i agree with you that this is the difficult part of an in-process approach.
> For example, it is not possible to dlopen KDE3 libraries from Qt3-only
>applications because of something called 'kapp pointer'. In a nutshell, every
>Qt application has exactly one so-called application object inheriting from
>QApplication, which KDE extends to KApplication, and kapp points to the
>KApplication instance - however Qt-only apps create QApplication and so it's
>not possible to create KApplication, so the kapp pointer cannot be valid.
>Because of binary compatibility reasons we can fix this only for KDE4.
Hmm - i guess KApplication shouldn't be a subclass of QApplication...
Do you think this could be solved by creating a KApplication instead of
a QApplication for a Qt program? For instance the desktop adapter could
provide an init_backend() function, which should be called before
creating the QApplication:
I->init_backend(...); // creates a KApplication if the desktop adapter
runs on KDE.
if (!qApp) new QApplication(...);
I'll try to analyse that particular problem with my prototype. AFAIK
Gnome and Gtk+ are easier to deal with here.
> And this problem exists when trying to combine Qt and KDE (in a rather
>unusual way, indeed), two things that are otherwise very close, because KDE
>depends on Qt. Even though in this case that was probably rather the problem,
>which one shouldn't have with two totally independent toolkits, can you be
>really sure you won't have other unexpected interactions when mixing two or
>more completely different codebases? You can have them sometimes even when
>using just a single codebase.
Is it only global variables like qApp or are there other troublemakers too?
> Moreover, now that I think of it, I wonder if some ISVs wouldn't have issues
>with loading other large libraries into their applications, for whatever
Hmm... But on the other hand out-of-process would give them a 3rd class
ticket for the desktop ride. ;-)
> Of course, out-of-process approach has its disadvantages too, just different
>ones. We need to compare the approaches after we specify the problem. And we
>haven't done that very precisely yet.
I agree. It always depends what you wanna do. File-dialogs would be
possible out-of-process. High performance stuff like VFS will be harder.
More information about the Portland