On Thu, Jun 25, 2009 at 10:38:52AM -0500, Shawn Walker wrote: > On Jun 25, 2009, at 7:20 AM, Michal Pryc wrote: > >One solution would be to add the lock mechanism in the GUI, but I am > >not sure if this would be better solution then adding such mechanism > >in the api itself. There is already lock mechanism in the api for > >other purposes. > > While it makes sense for the transport layer to have a lock, shouldn't > the GUI not bother attempting to perform these operations given that > modal nature of the install/update dialogs and to avoid the > unnecessary overhead of a waiting background thread?
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. (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.) Nico -- _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
