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
