On Mon, Jan 25, 2010 at 03:34:00PM -0600, Shawn Walker wrote:
> As for the generator bit, if the wrapper function does something like:
>
> try:
> return self.__generator_func()
> except ...:
> ...
> finally:
> ....
>
> ...it will be fine. There's no real difference between returning a
> generator (as shown above) or calling the generator directly.
>
> I might still be missing something here though.
Is this going to work properly with locking, though?
If __generator_func() needs to hold a lock as long as it is returning
results, won't releasing the lock in the finally statement cause the
lock to get dropped after the generator is returned to the caller?
That's not what's desired, I think, since we want the lock held while
the generator is running.
This also raises another interesting question about holding locks in
these functions: if the caller never runs the generator to completion,
at what point does python destroy the generator object? What happens to
the locks that are held? Does this mean that we need to drop and
re-acquire any locks around a yield statment? (I'm guessing the
answer is yes.)
If the answer is yes, we don't really want to drop and re-acquire the
activity lock, and disable/enable cancel every time this function
yields.
I think this means we really want to do something like:
def remote_search_wrapper():
activity_lock.acquire()
enable_cancel()
try:
r = remote_search()
while r:
yield r
finally:
disable_cancel()
activity_lock.release()
However, I don't know whether this will cause all of remote_search()'s
results to be held in memory, or if this will just return True as long
as the function still has results to return. Is this documented
anywhere?
> >>>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.
> >
> >That's broken. The whole point of having an assertion failure is to
> >failfast and exit.
>
> We may wish to document that in the docstring for pkg.client.api.
> Since AssertionError inherits from the Exception base class, that
> would mean all clients need a special handler for AssertionErrors.
>
> I'm also not certain that the GUI client should just exit right
> away, although at the very least it should re-create its existing
> API objects.
I'm fine with destroying and re-creating the API object, if the
AssertionError is logged in the history.
> >>1821
> >
> >This doesn't re-raise the exception once it's caught. This ought to be
> >safe.
>
> The thought was that the origin may be invalid, but I suppose we
> should assume that user input has been validated first.
Ah, so you mean that you're expecting another exception besides the
UnknownPublisher that's already being caught?
-j
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
