icons for Settings Manager
benedikt.meurer at unix-ag.uni-siegen.de
Wed Jan 14 23:42:40 CET 2004
edscott wilson garcia wrote:
> On Wed, 2004-01-14 at 12:20, Benedikt Meurer wrote:
>>Glib XML Parser is a light-weight SAX-style parser which should be quite ok
>>for our needs. I thought of letting mime-things be handled by a daemon process
>>and having a small communication library for setting up a fast UD socket and
>>retrieving the information from the daemon. This approach has some advantages,
>>just to name 2 of them (while it has some disadvantages of course):
>>1) Mime config/icon files can be held/cached in memory in the daemon process
>>and need not to be parsed whenever information is required, that should lower
>>the I/O overhead and allow for faster operation (depending on the quality of
>>the UD socket implementation in the target system)
>>2) Processes load only a thin wrapper library with only the socket code.
> I like this idea. Currently each process has to parse the xml and create
> it's own g_hash_tables. Startup times can certainly be reduced if only
> one copy of the g_hash_tables is used (except for the first application
> which requires and therefore starts the daemon). We only need to be
> careful to resolve race conditions when two different applications both
> try to start the daemon at the same time.
Starting the daemon should be quite easy using a locking technique similar to
1) try to connect
2) if that fails, shlock on a well-known lockfile
3) gathered lock: try to connect (maybe someone else started the daemon in the
4) if that fails, start the daemon
5) unlock the lockfile
Step 1) is optional, but allows for faster startup if daemon is already
running (safes the lock()/unlock() procedure which is quite expensive for
shlocks). We could also use SYSV Semaphores (see sem_open(3)), but they are
not supported very well by all systems, so they could be first choice but with
a fallback to generic shlocks.
>>Using SYSV shm and IPC techniques could allow us to speed up the stuff even
>>more, for example transferring pixbufs between processes using shm segments.
> Or maybe have the daemon place its g_hash_tables and icon factories in
> shared memory segments so applications can access them directly.
The problem with g_hash_tables is that data is allocated on the heap
internally which is therefore not shared in the shm segment and pointers would
not be valid in the context of another application that maps the same shm
segment. To make it even harder, the virtual address of the shm segment is not
garantied to be mapped to the same address in all applications, so pointers
even within the shm segment are useless and dangerous. Therefore we would have
to develop our own data structures and algorithms if we'd decide to use shared
>>But this was just a thought I had last year while I was looking for an easy
>>and efficient way to bring MIME to XFce. Any comments to this?
> Your ideas sound very good. At the moment I don't know how difficult
> they would be to implement. It certainly sounds interesting to try and
Actually I dropped that idea because at that time I thought it'd be to
difficult to develop. Whereas I think the implementation should be quite easy,
but the analysis and design steps could take a lot of time and energy, since
we would have to develop
a) a flexible and easy to implement wrapper API
b) a fast and flexible data exchange layer (esp. in terms of SHM w/ fallbacks
and error handling/recovery)
c) a stable and fast backend (the actual daemon)
Only looking at c), speaking of things like security (esp. authentication),
portability (different socket implementations, different shared memory
techniques), performance and stability (its a daemon!) makes me believe that
this is indeed a non-trivial task.
And if we should really decide to give this a go, then we should propably
think of adding things like .desktop file handling and configuration handling
to this framework as well, so that we have (nearly) all parsing of files in
one central daemon (using several caching techniques to speed things up)
instead of having each application parse several files each time it fires up.
From what I think, the fact that we are "distributed all over the planet"
makes things even harder, cause we cannot just sit down in front of the
whiteboard and discuss various solutions using well-known modelling
techniques; and I'm not sure if this can be done as a one-man-job.
Anyway I still think that this is a good-to-have with XFce. Having a single
process that handles configuration and all kinds of meta-information should
increase the quality and maintanability of XFce a lot. For example, if we
implement our own configuration framework on top of this new architecture
using our own XML backend at this time, we could later on switch to D-BUS,
GConf or whatever system by simply modifiying one module in one application
instead of having to alter nearly every application. We could also provide
different configuration backends for XFce by default.
Anyway, everybody should be clear that this is not an easy task to finish and
will take several months (esp. since we are all busy with other things and of
course with XFce components, jasper with the panel, edscott with xffm, botsie
with <dont-know>, olivier with everything and I am currently breaking the
session manager again).
(Lots of words but nothing really said :-)
NetBSD Operating system: http://www.NetBSD.org/
pkgsrc "Work in progress": http://pkgsrc-wip.sf.net/
XFce desktop environment: http://www.xfce.org/
German Unix-AG Association: http://www.unix-ag.org/
OpenPGP Key: http://www.home.unix-ag.org/bmeurer/#gpg
More information about the Xfce4-dev