[pclasses-devel] plugin registry thoughts

[stephan b. <st...@s1...>]

Yo!

Going back to the idea of a plugin registry for a moment...

Some background detail to explain why this is useful, and arguably even 
necessary:

The current classloader/factory model allows any number of classes to 
register themselves with our factories, even if we have 0% chance of 
ever using those classes in our code. While this isn't a major problem 
for most purposes, for P this extra potential bloat might become a 
problem when P is acting as, e.g., a service provider for many 
applications running on the system (ArkLinux or Helvetix). i.e., if the 
uptime of the system is also the uptime of P, then this could 
essentially result in a long-term leak. In the case where P is used 
only for individual apps, as opposed to a framework, i think the 
potential "leak" is irrelevant, as closing the app cleans the 
couple-byte leak. (To be clear, it's not *really* a leak, but it is a 
blatant waste of resources.)

A potential solution came to mind today:

When Factory::create(classname) is called, we count how many times any 
given classname is passed. In a garbage collector thread we iterate the 
factory maps every now and then and remove any factories which have 0 
hits.

The implementation for the actual tracking would be fairly trivial: one 
more map added to Factory, which gets modified during create(), plus a 
cleanup function:

public:
	size_t cleanUnusedFactories();
	// returns # of factories cleaned

private:
	static map<string,size_t> & hitsMap();
	// maps classnames to create() call counts


The GC thread would then call 
Factory<T>::instance().cleanUnusedFactories() every X seconds (5+ 
minutes is probably reasonable, or after every X factory registrations 
we check for unused facs). i propose to make hitsMap() internal so that 
we can achieve safe locking more easily. If hitsMap() is public we 
don't need cleanXXX(), as any 3rd-party code could directly manipulate 
the factory map. While this isn't a problem in and of itself, it might 
become problematic in a multi-threaded environment. Thus the cleanXXX() 
member, to simplify any potential locking.

More complex variants might track how long ago a given factory was used, 
or how often, or use a LRU algo with some built-in limit of factories 
to hold on to.

???

-- 
----- st...@s1...   http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts