[packagekit] pk_backend_finished race issue

[Tom Parker]

Richard Hughes wrote:
> That would make sense. The thread calls pk_backend_finished and we
> then try to unload the module as the thread is still running.
> 
> Surely we can fix this simply by just causing the unload to wait for
> say one second (after getting ::finished) in the backend code, surely
> enough time to finish the thread and exit.

Ew... not a fan of that. I can see various ways to solve this more 
cleanly, mainly with things like having a list of threads "associated" 
with each backend, providing a function to use to wrap g_thread_create 
that adds threads to the "associated" list and doing a bunch of 
g_thread_join's before unloading modules.

Here's a better question tho - why unload backend modules immediately? 
Or even at all? One of the things I'd really like to do with the apt 
backend is in-memory caching of the references to the package database. 
Something I really dislike with the current apt tools is that every 
bloody time they *individually* parse the database files, and when 
you're running a sequence of apt commands in a row it would be nice if 
they kept that sort of information in memory for at least a minute or 
two.... which would be the sort of thing I'd expect an apt-backend for 
PackageKit to do, and I've started work towards that.

Admittedly it needs some work to make sure it plays nice with the 
existing apt commands (letting go of write-locks the moment it doesn't 
need them for example; rebuilding as and when needed), but if PackageKit 
is repeatedly loading and unloading the module then there's not much I 
can do, and then we're back to dog-slow responses to every command, not 
just the first one. I would like to avoid this.

Depending on the backend-specific processing time/memory trade-off, 
maybe other backends don't mind being completely unloaded every time, 
but I'd like it if it wasn't compulsory.

So, why not just load the requested backend immediately, and keep it 
loaded throughout the program?

Tom