On Fri, Dec 11, 2009 at 04:35:50PM -0800, Stephen Hahn wrote: > api.py: > > 207. What would cause api_errors.CanceledException to be raised > here?
After some looking around, I'm not sure why that's there. I'll remove it. > 328. I wonder if > > self.__cancel_lock.acquire() > if self.__canceling: > self.__cancel_lock.release() > raise api_errors.CanceledException() > else: > self.__set_can_be_canceled(False) > self.__cancel_lock.release() > > should be a function. It seems to recur as a test for > cancellation requested. This is really a way to make sure that we don't set can_be_canceled to False while another thread has gone to sleep on the cv. I'm making sure that there are no missed wakeups, essentially. I'll put that it its own function. > 1652. (Sp.) "canelation" -> "cancelation". Changed to "cancellation." > engine.py: > > 770. Who's expected to use progfunc of our current clients? Any caller that's not using a progress tracker. This would be all of the transport methods that deal with a file object instead of performing tranfers in batch. > transport.py: > > 106. Shouldn't this be > > fobj = self._do_search(pub, data, ccancel=ccancel) > > ? Similarly on 188, 519, 559, 1099, 1121, 1317, and maybe one > or two more. The arguments are in the correct order, making the kwarg format optional. I can change this to ccancel=ccancel, if that's our preferred style in this situation? > 1280. Can just omit ccancel here. Fixed. > 1327. Tracking bug? Oops. I actually need to fix this to set __portal_test_executed to False if a CanceledException occurs in this path. Thanks for looking at this! -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
