jmr wrote:
Currently the client API implements locking which is a key assumption
in how the code is structured in the GUI (we assume the API tasks can
take some time so we kick them off in background threads and allow
them to update the GUI asynchronously). The only API call that doesn't
lock which we need to is the api.info call, the api.info should also
acquire the lock as does all the other, plan, prepare, execute and
refresh api calls.
I disagree. Fundamentally, a single api object can only have one plan.
It can be creating, preparing, executing, etc, it, but only one can be
in existence. That was why it made sense to implement the locking inside
the top level of the api.
There's no fundamental reason that info should lock at all. I understand
that due to the transport method, it's necessary, but that's entirely
different than the plan issue. The locking needed for info is simply an
artifact of the changes that are coming in transport.
Should this be handled inside the api versus in the client, perhaps, but
be aware of the control you'll be giving up over how contention will be
resolved. If we place it inside the api, I would like to see this live
down in transport area.
Brock
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.
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.
JR
[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
