Re: Memory Resident Gtk 2 module

[Enrico Weigelt <weigelt metux de>]

* Amit  Bansal <amitdk29 rediffmail com> [2004-04-05 09:19:59 -0000]:

<snip>
>    How do I make a Gtk 2 module to be loaded once and be used for 
>    all subsequently spawned Gtk applications?

What do you want it for ?

On modern operating systems shared libraries are loaded only once
(the data pages are copied on write)

So one library is only loaded once the first application linked to 
it is started and remains in memory (at least in virtual memory) 
until the last process using the lib terminates. 

If you want to preload a library, you can simply write a little application 
just linking against this lib and waiting forever doing nothing. As long
as it is running, you can be sure the lib always in virtual memory
(this doesnt prevent it to be paged-out or the just mmap()'ed pages to
be released from physical memory).


But perhaps you want something different: the init stuff of gtk2 
(loading resources, etc) maybe takes too long. But you can't simply use
one runtime library image and copy it to other processes - each process
is an own virtual machine which may vary quite much from others in 
local adresses, linked libraries, etc. (on many operating systems 
dynamic linking happens completely in usespace)

You can beat this problem by a completely different approach, which also 
beats the process starting at all: 

Write applications as applets, which are just modules for an applet framework.
For many GUI applications it is enough having many applications living in 
the same process (probably using multiple threads). The applet itself would
live in a library coupled w/ a small applet description file, which can
be loaded from a generic applet runner application. Each applet may also
register several services (usable from other applets or also be bridged
to other processes by some IPC, i.e. corba) and provide several entry 
points for several purposes. 

Lets take some examples:
    
    * desktop icon applet or tray applet
    
	-> provides IDesktopIcon interface, which maybe allows us to 
	   ask for properties, set some, retrieve a list of menu entries, ...
	-> allows sending signals, i.e. "doubleclicked" or "menu activation"
	
    * image viewer / file viewer
    
	-> provides IFileViewer interface, which lets us to throw in a
	   URI and tell him to open a new file viewer instance
	  
    * several gimp modules
    
	-> large GUI applications like gimp could also use this framework
	   interanally for managing several modules, i.e. load-on-demand
	   of features (i.e. filters, tools, ...)

	-> code can be easily shared with other similar applications 
	   (i.e. dia or an office application)


Especially very small applets doing not very much can benefit quite much
from such a framework, since they a) save a lot of code and b) reduce
the overhead of separate processes (w/ all loaded libs, init stuff, etc)
dramatically.


I've posted my suggestions some years ago - but nobody really listened.
Maybe now it's time for such a project ?



cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     contact metux de
  cellphone: +49 174 7066481
---------------------------------------------------------------------
   -- DSL-Zugang ab 0 Euro. -- statische IP -- UUCP -- Hosting --
---------------------------------------------------------------------