[packagekit] pk_backend_finished race issue

[Richard Hughes]

On 13/09/2007, Tom Parker <palfrey at tevp.net> wrote:
> 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.

Yes, this is a very good idea. We can abstract this nicely with a
pk_backend_thread_create (PkBackend *backend, PkThreadFunc func)
function, and then on backend unload we go through the list and join
the threads.

> 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.

Well, basically it's a design decision that each PkBackend instance is
a new object with properties. As soon as you let the backends do job
control things get very complicated very quickly. I prototyped this
before PK became PK, and it was a huge complex mess, hence the current
design.

> 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.

Yes. I've been told PK will be dead in the water if it hangs onto the
yum lock after a transaction, as that prevents using the command line
tools. What in the apt backend takes so long to load?

> 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.

I'll think about how you could share data, but I'm not sure this is a good idea.

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

See above. Job control does not belong in the backend.

Richard.