[email protected] wrote:
On Fri, Jun 26, 2009 at 12:07:13PM +0100, jmr wrote:
If api.info supported locking as does the rest of the API then the issue
we currently have with descriptions and licenses being fetched when a
user goes and does some other API action, would not arise. There might
be a slight delay in the progress starting but the GUI would still be
responsive. The API tasks are all being kicked off in background threads
and calling back to the GUI to update progress and so on.
I'm surprised you haven't filed a bug for this. I just filed:
9715 The info() operation should use the activity_lock
My omission - thanks for filing it.
With regard to the CLI there should be no impact on acquiring the lock
as it is carrying out a single linear task and then exciting, unlike the
GUI which can be carrying out a number of tasks simultaneously and all
have to be managed, including keeping the GUI responsive and up to date.
Ok, but I don't think you answered my concern from the previous e-mail.
If the background thread is taking a long time to download manifests,
it's going to hold the activity lock and potentially starve out callers
who are trying to perform an install/update operation. How do you plan
to cope with this scenario?
Well we are only fetching small chunks of descriptions now (just the
visible rows), so presumably, this should not block for too long. This
is being done in the background as far as the UI is concerned so the
user can click on Install and it will proceed. The install task itself
will appear to the user to have started, the UI will be updating and be
redrawn appropriately, but the user is blocked from doing anything else
with the modal install dialog. The impact is possibly a slight delay in
the initial progress update, until the api.info lock is released and the
Install task can grab it and proceed.
JR
-j
[email protected] wrote:
On Thu, Jun 25, 2009 at 10:47:40AM -0500, Nicolas Williams wrote:
There are plenty of MT-safe APIs that leave locking to the caller (e.g.,
"only one thread may be active in a given blahblah handle"). Adding
locking to the API's implementation makes it easier on threaded
callers, but then non-threaded callers pay for needless locking.
Which approach is best is generall context-specific. In this case I
think the PM GUI can do the locking that the CLI doesn't need, so IMO:
leave locking to the caller.
After sleeping on this, I agree with Shawn and Nico -- thanks to both of
you for chiming in here.
If we preemptively put a lock in the transport, the running background
thread is going to block any install/update operations that the user may
try to perform. Unless it's handled carefully, it will look to the user
like the GUI has just hung, which is hardly the user experience that
we're aiming for. I would recommend that the GUI quiesce the background
thread prior to performing user-requested network operations.
(Also, the transport is really cool, and should be a standalone facility
for use by any other apps that might come along and need this.)
Thanks. The current incarnation is pretty pkg(5) specific, but with
more time and polish it could be turned into a more generic set of
libraries.
-j
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
