[Lumiera] Application startup and shutdown, GUI loading

[Christian Thaeter]

Ichthyostega wrote:
> Christian Thaeter schrieb:
>> For resource management I plan something to recover resources incrementally
>> by letting different parts of the application register handlers which free
>> cached resources.
> ...
>> every subsystem which allocates resources which are not extremely vital 
>> (anything which can be recovered somehow, maybe costly) registers handler
>> functions which voluntary try to comply with the request to free resources
>> iteratively.
> 
> ...sounds like an very interesting idea. Probably something going on deep
> below the hood, but, anyway, creating an application which can adapt itself
> to the current situation this way seems to be something really cool.
> 
> Maybe we can extend this idea even to something like "futures"?
> Remember, we often considered that we might do this or that in expectation
> of the users next movements in order to get the application more responsive.
> Well, doing too much prerendering might drain resources needed much more
> for another operation, i.e. there could be such a negotiation going on
> about using resources from a finite pool for precalculating expected
> operations.....  well... just brainstorming :-)

Prefetching/Prerendering would be part of the normal scheduler logic and
be weighted there, I am rather against extending this resource
collector. Some points to consider:

 * Some boundaries can only be found out by crashing into them. For that
   the resource collector is a quite fragile thing (but still far better
   than nothing).
 * not all parts (plugins/codecs) voluntary use this collector. There
   are still some cases left where it cant help and there will be an
   error (at best, a codec which doesn't report the error back but
   crashes would be worst)
 * The resource collector can be called anytime, even if it is
   inconvinient, freeing resources might be expensive. This should be
   reserved for extreme situations and then do the least possible it can
   do.

Generally I am about optimal resource utilization. For many resources
this equals to minimize them (but not less), for others we set artifical
high limits and then backoff this limits, either by online
profiling/statistics or by the resource collector.

In the backend I use caches extensively. This are lists where used
elements are moved to the head and things not used propagate by this to
the tail. When new objects are needed these are just recycled from the
tail. This caches could be quite simple profiled by hit/miss counters
and are either static sized (when the amount of resources is fixed, like
filehandles) or growing dynamically to a certain limit which gets
automatically adjusted. The 'big' memory blocks for video and audio data
are managed by the kernel, we dont need to care much about them (except
adding a IOBANDWIDTH resources to the above and adjust that). There are
certainly some more resource to discover which need to be handled.

	Christian

> 
>> In real the above memory allocation would be already wrapped by 
>> lumiera_malloc() and I suggest to wrap other allocators (C++ factories) in
>> this way too.
> That's the way I expect it to work too. For any large-scale non-trivial
> allocations, on the long run we'll use some custom allocator, factory or
> similar, which delegates to the backend, which thus gets an centralized
> view on the memory requirements of the application.
> 
> 	Hermann
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Lumiera mailing list
> Lumiera at lists.lumiera.org
> http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera