[email protected] wrote:
[snip]
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?
That's part of the concern; however, the other part of the concern is
that there's no way to add another level of indendation to remote_search
without making the function unreadable. My other concern was how to
appropriately wrap the remote_search, a function that calls yield, with
another function that has the try/finally block and still retains the
functionality of a generator. I had thought that if I tried to iterate
over the response from remote_search and yield that instead, I would
pull all of the search results into memory.
Please, please don't pull all the results into memory. Besides causing a
potential explosion in memory usage, it also may cause a substantial
delay before the user begins to see results.
I'm probably just not thinking clearly this morning, but what's wrong
(other than indentation issues) w/
a try at 1772 and a finally at 1881 or 1888? This would mean that
(appropriately) remote search would hold the activity lock until it was
finished processing all results and no longer was cancelable, or
encountered an error and could no longer be canceled. Wouldn't it?
Brock
[snip]
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
