[packagekit] viability of the current yum backend ?

[James Bowes]

On Jan 8, 2008 12:05 PM, Robin Norwood <rnorwood at redhat.com> wrote:
> Richard Hughes <hughsient at gmail.com> writes:
>
> > On Thu, 2008-01-03 at 08:22 +0100, Tim Lauridsen wrote:
> >> You are right, it sucks to setup yum each time we do some kind of
> >> packagekit backend action, the way to do it is have some kind of
> >> persistence yum object loaded one time and let the the helper script
> >> call it over DBUS.
> >
> > Agreed.
>
> So how does this work, exactly?
>
> Something like:
>
>    C Backend                          Python Backend
>        |
>      Start
>        |
>  Start python backend --(exec and fork?)--Start
>        |                                    |
>        |                                    |
>   Run an action ----------DBUS--------> (Do Stuff)
>        |                                    |
>  Receive results <--------DBUS--------- Send status update
>        |                                    |
>      (etc)                                (etc)
>        |                                    |
>     Keep alive -----------DBUS----------->  OK
>        |                                    |
>      (etc)                                (etc)
>        |                                    |
>     "Die now" ------------DBUS----------->  OK (clean up and die)
>        |                                    |
>      Exit                                  Exit
>
>
> (Sorry for the diagram)
>
> Where the current backend lifecycle remains pretty much the same - It
> starts upon receiving the first action from the frontend, and persists
> for a certain amount of time after the last action in case another
> action is on the way.  Except now, isntead of spawning a process for
> each action, and waiting for the results on STDOUT/STDERR, it spawns a
> single process, and talks to it over DBUS.  The python process sticks
> around until it receives a "die now" from the backend, or it stops
> getting 'keep alive' messages (in case the backend crashes).
>
> Is this about what you're thinking?

So if that's the case then that python daemon is going to have to be
threaded to handle any actions that can be run in parallel, right?
Maybe not for the yum backend, as it really can't do anything in
parallel, and we could have packagekitd be aware of if it has a
request out already, and hold off until that request returns before
sending a new one.

We could also keep with the subprocess spawning, but have the
communication be two way over pipes, so that after you have
initialized one subprocess you could keep using it after it served the
first request. This would also allow for the current model of multiple
spawned subprocesses at the same time in backends that support
parallel actions.

-James