On 01/25/10 01:51 PM, [email protected] wrote:
On Sat, Jan 23, 2010 at 04:26:03PM -0600, Shawn Walker wrote:
http://cr.opensolaris.org/~johansen/webrev-3720-3/
...
line 1772: does this need to be wrapped with try:/finally:
activity_lock.release() in case enable_cancel fails?
This is a generator function. I didn't see a tidy way to wrap this in
another function with try/finally and have things work correctly.
It doesn't matter if it is a generator function. Python 2.5+ guarantees
the finally bock will be executed:
http://docs.python.org/whatsnew/2.5.html
"...This last chance means that try...finally statements in generators
can now be guaranteed to work; the finally clause will now always get a
chance to run."
Or did I misunderstand the concern here?
Enable_cancel can't fail unless there's an assertion failure. My
understanding is that these should propogate to the top and cause a
traceback. I don't think we need to worry about that particular case
here.
Yes, they may cause a traceback, but in the case of the GUI, the client
won't exit after that traceback, so I believe the lock still needs to be
released in relevant exception scenarios.
Likewise, it looks like if an exception happens in several spots in
here that the activity lock may not be released.
Which spots? I went through this code pretty carefully to catch the
places where it looked like there might be an uncaught exception. If
you think I've missed one or more, would you please provide specifics?
line 1775, 1779-1780, 1821, and 1569 (the cancel state callback could
raise an exception) seem like candidates. There may be others related.
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
