|I've just uploaded http://pliant.cx/archive/pliant-85experimental23.tgz
It contains the first implementation of Pliant global cache.
The global cache is basically a dictionary. You can store there objects,
then access them through an ID (a path).
The engine is responsible for discarding some of the object when the consumed
memory goes too high.
The global cache engine is implemented in /pliant/pliant/language/data/cache.pli
It's already used at several places:
. in /pliant/appli/database/split.pli in order to store splitted database
(a splitted database is a database where each record of some table is stored
in a different file, so that not all of them need to be stored in the memory
all the time)
. in /pliant/graphic/vector/font.pli in order to store loaded fonts
. in /pliant/protocol/http/common/cache.pli in order to cache some server side
computed image (used in /pliant/protocol/http/style/draw.pli for handling
server side on the fly generated images as used in the Pliant photos editing
tool, in /pliant/protocol/http/common/virtual_tree.pli for storing server
side rendering text, icons, corners, etc)
The global cache is configured through two global variables defined
in module /pliant/language/context/memory.pli
. 'memory_assigned' specifies how much memory the Pliant is assigned, so how
much it should use most of the time
. 'memory_overflow' specifies a limit that Pliant must not exceed in any case.
If the limit is reached, Pliant will crash itself.
All this is very convienient for reliably runninng logical computers in
FullPliant. Assuming that you have a FullPliant box with 512 MB or RAM,
and use two logical computers for running your applications.
Then you could assign 128 MB to each logical computer, and set the limit
to 256 MB.
Basically, a rule of thumb is that the some of assigned values should be
roughly half the total available memory, and the sum of the limits should
be roughly all the available memory.
If anyway, some of the Pliant process eats too much memory, then Linux
kernel will decide which process to kill, but if it selects Pliant, it will
kill the threads one after the other, so the stack trace you will get will
be the one of the first thread, general not very interesting because not
the one of the ungry thread that decided to eat too much memory.
Having Pliant crash itself simply makes it more likely that what it will
output be more meaningfull to help improve the situation.
The downside is that now Pliant needs to be more precisely configured.