[packagekit] Yum and locking
tla at rasmil.dk
Thu Oct 18 22:51:15 PDT 2007
Richard Hughes wrote:
> On Thu, 2007-10-18 at 16:30 -0400, Robin Norwood wrote:
>> Richard Hughes <hughsient at gmail.com> writes:
>>> On Thu, 2007-10-18 at 10:59 -0400, Robin Norwood wrote:
>>>> Cool. However, it looks like the way things are now it will just
>>>> if something else has the lock - shouldn't we wait around awhile, and
>>>> perhaps notify PK with a signal?
>>> What I would rather do is make the daemon aware of what can be
>>> scheduled, when.
>>> I.e. each backend would have a function:
>>> return PK_ROLE_ENUM_SEARCH_GROUP | PK_ROLE_ENUM_SEARCH_GROUP
>>> return PK_ROLE_ENUM_REFRESH_CACHE
>> Not sure if I follow exactly what those are supposed to do.
> Sorry, I should have explained it better. The first is "what can i do
> with other stuff going on", e.g. it's okay to do a SearchGroup when we
> are installing as it works readonly without updating anything.
> The second is "what has to be done on it's own, even holding up the
> first list", so for instance a cache update probably should invalidate
> all internal caches and so even searching wouldn't be valid for that.
> This idea might be cractastic, probably very, in fact.
> I'll have to have a look at the transaction-list code in more detail to
> see if the spawned executable can put itself in the waiting state; it
> should be enough to do "status<tab>wait" in the spawned code and spin.
> In this case in the UI and queue it should do the right thing.
> Could one of the yum guys do:
> if locked:
> print "status\twait"
> loop until unlocked
> print status\tdownloading
> And see if this works? If so, it's a nice solution to the problem.
I have add a slightly modified version of the looping locking code Robin
It will try 100 times to get the lock with a 2s delay, it will submit a
'status wait' before each delay
>>> So the daemon knows what to do. Have a look in
>>> pk_transaction_list_commit in src/pk-transaction-list.c for inspiration.
>> It seems fragile to have the daemon ask 'can I do it?' first, and then
>> do it - and racy in that on occasion something will swoop in and grab
>> the lock between the asking and the doing...and then we'll have to
>> handle the case where something else has a lock anyway!
> Sure, that's racy as hell, and not what I was suggesting :-)
>> This should be an exceptional enough case (I hope) to just have a simple
>> notification that something else has the lock. Is there a way to have
>> the backend say "I can't do this right now, try again later?" - that way
>> we wouldn't have to have the backend do the waiting as in my example,
>> the engine could just put the action back on the queue and try again
> Then we are polling. If we know the command will wait for a lock then we
> shouldn't schedule it yet, or put it into thw wait state manually. For
> the case of a user using yum on the command line then I agree it's a
> problem, but that's a separate issue in my opinion.
>> Really, in the long term, for fedora this should only happen if someone
>> happens to want to use yum from the commandline. It will probably
>> happen more often for awhile when people are still used to using yum
>> from the commandline, and when things like yum-updatesd are still
>> running (and not using PK! :-))
> Heh, yum-updatesd doesn't make sense with PackageKit, so I would ignore
> that use case scenario :-)
Why not, the yum-updatesd is installed by default on all fedora systems
and yum has a plugin triggering yum-updatesd each time it is run (by DBUS)
Even if PK is doing some of the same things, then yum-updatesd is a
player we have to deal with.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the PackageKit