<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Richard Hughes wrote:
<blockquote cite="mid:1192746571.2850.10.camel@hughsie-laptop"
type="cite">
<pre wrap="">On Thu, 2007-10-18 at 16:30 -0400, Robin Norwood wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Richard Hughes <a class="moz-txt-link-rfc2396E" href="mailto:hughsient@gmail.com"><hughsient@gmail.com></a> writes:
</pre>
<blockquote type="cite">
<pre wrap="">On Thu, 2007-10-18 at 10:59 -0400, Robin Norwood wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">Not sure if I follow exactly what those are supposed to do.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
I have add a slightly modified version of the looping locking code
Robin posted.<br>
It will try 100 times to get the lock with a 2s delay, it will submit a
'status wait' before each delay<br>
<br>
<blockquote cite="mid:1192746571.2850.10.camel@hughsie-laptop"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">So the daemon knows what to do. Have a look in
pk_transaction_list_commit in src/pk-transaction-list.c for inspiration.
Ideas?
</pre>
</blockquote>
<pre wrap="">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!
</pre>
</blockquote>
<pre wrap=""><!---->
Sure, that's racy as hell, and not what I was suggesting :-)
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
<blockquote type="cite">
<pre wrap="">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! :-))
</pre>
</blockquote>
<pre wrap=""><!---->
Heh, yum-updatesd doesn't make sense with PackageKit, so I would ignore
that use case scenario :-)
</pre>
</blockquote>
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)<br>
Even if PK is doing some of the same things, then yum-updatesd is a
player we have to deal with.<br>
<br>
Tim<br>
</body>
</html>