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
> 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?
-j
> johan...@sun.com 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
>> pkg-discuss@opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
>>
>
> _______________________________________________
> pkg-discuss mailing list
> pkg-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
_______________________________________________
pkg-discuss mailing list
pkg-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
