[packagekit] Yum and locking

[Tim Lauridsen]

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
>>>> abort
>>>> 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:
>>>
>>> get_no_queue_objects:
>>> return PK_ROLE_ENUM_SEARCH_GROUP | PK_ROLE_ENUM_SEARCH_GROUP
>>>
>>> get_force_all_queue_objects
>>> 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"
> 	do
> 		yield
> 	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 
posted.
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.
>>>
>>> Ideas?
>>>       
>> 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
>> later.
>>     
>
> 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.

Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/packagekit/attachments/20071019/1f4a6517/attachment-0002.htm>