[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: (kded/registries/konqy) Re: kdelibs/corba/kded
From:       Simon Hausmann <tronical () gmx ! net>
Date:       1999-05-31 14:52:47
[Download RAW message or body]

On Mon, 31 May 1999 weis@stud.uni-frankfurt.de wrote:

> Hi,
> 
> I get more and more the impression that shared mem is a good
> way to go. It would mean that only KDE apps which really
> want to start CORBA components need to link with libmico and friends.
> All others just access the shared mem.

Yes, sounds nice.
 
> The biggest task to solve however, is to come along with semaphores.
> And here comes our next problem:
> 
> If some app gets a semaphore and dies. Is the semaphore released
> by the OS. I think som but we have to be shure.

hmpf, always these worst-case scenarios... ;-)

AFAIK using SysV style semaphores (semget,...) leads to such a leak :-(
So I guess we'll have to go the use-filesystem-mmap-style of sharing
memory and locking the file via fcntl.
Or?

> When KRegistry is updating data, nobody may do reading.
> A little problem is that we wont have a QMap etc in the
> shared mem. That means we will loose this fast access.
> 
> About the mimetypes and services ( not the CORBA ones! ).
> I have written some code for Kregistry which allows to
> save the registry in a binary format. The code is still in, or ?

Yes, it is.
(though the last time I tried it it crashed)

> kded when first started creates KRegistry from the binary file,
> updates it and writes it back if the update caused changes.
> Whenever the KRegistry changes we write the binary back.

Yes, it does so already :)
 
> When a non CORBA app is interested in mimetypes, usual services
> etc. it can just pull in this binary file and use it via libkio.
> Most apps dont need to update their mimetype/service information
> during runtime.

But: Kded saves the updated kregistry binary file only when shutting down,
so apps will always read the old registry, until kded gets restarted and
flushes the binary file.
Or?

> Even more lamer apps could still use something like kfmclient
> to open some document or whatever.
> 
> That means we can serve everything except the power apps
> without any CORBA. But power apps want to use full libkio
> functionality, too.
> 
> SO: kded is responsible for
> a) all CORBA services and activation of them
> b) updating KRegistry and writing the binary file
> c) sending diffs via CORBA.
> 
> c) means that powerapps like konqeror read the binary file
> and connect to some kded event channel which informs about the
> differences.

This sounds like an interesting approach.

> All that means: Use CORBA only where really needed.
> Still fast startup since reading the binary is MUCH faster
> than reading all kdelnk files and *.xpm files IMHO.
> Even konqueror does not need to talk too much with kded
> since it holds a always actual copy.
> 
> The problem with this approach is memory usage. I optimized
> here for few CORBA and speed. How much memory does a full
> filled Kregistry need ?

That's really a problem IMO. I mean a registry can become really big if
you have lots of .desktop files installed.
I'd love to find a way to have the registry in shared memory.

<wild_guess>
Perhaps we can share the binary registry file via mmap in some way?
So that kded puts any updates directly into this file, which is shared
among all clients (read-only) .
</wild_guess>

<even_stronger_wild_guess>
Perhaps this could be integrated into libkio, so that the registry as is
does not exist in the usualy way anymore but instead as binary data block,
which is read by client functions and managed (written) by server
functions (called from kded) . This way we'd have one single registry in
the whole system, which always reflects the "real" registry in applnk with
all its .desktop files
</even_stronger_wild_guess>

...just guessing ;-)

Ciao,
  Simon

--
Simon Hausmann       <hausmann@kde.org>
http://www.kde.org/  <tronical@gmx.net>

[prev in list] [next in list] [prev in thread] [next in thread]