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

List:       kde-devel
Subject:    Re: KApplicationServer?
From:       Tim Jansen <ml () tjansen ! de>
Date:       2002-08-25 22:28:35
[Download RAW message or body]

On Monday 26 August 2002 00:10, Friedrich W. H. Kossebau wrote:
> But there is room for improvements as you cannot say by a visual flag or
> like which windows are run by the same process (and by this share some
> settings!).
> No idea how this might help joe user (and not confuse ;).

I guess it would confuse 95% of all users.. (and it doesnt make a good 
impression when an app has features to reduce the harm caused by its crashes 
:)

> So forking is faster only for the start of the process, not the
> resetting involved? But as you wrote below the burden might be the
> programming...

You are talking about a lot of extra-code to cleanly shut down all connections 
inherited from the parent process and to create new ones, only to solve 
symptoms of a problem that is caused by other components (admittedly, 
components that are not part of the KDE project).


> But still I wonder why there cannot be a reuse of the readonly parts of
> an executable already loaded in memory which I understood machine
> instructions to be, too (section ".text", isn't it?). 

As far as I understand it, the problem is that each executable that uses 
shared libs can not be read-only. The locations of the symbols in the shared 
lib are not know at compile-time, so the dynamic linker must "patch" the 
executable after loading. glibc 2.3 should solve the problems by giving all 
shared libs a default location. As long as all code is at its default 
location, the dynamic linker does not have to patch it anymore. (And yes, it 
means that you must run some program after installation and determine good, 
non-conflicting default locations for all libs, at least for those that you 
will use together)

bye...

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]