On Mon, Jan 25, 2010 at 05:34:06PM -0600, Shawn Walker wrote: > There's one more option. We can require callers to call the new > generator close method on the returned generator object (the value > returned by a generator initially) and then rely on the finally > cause for cleanup:
Thanks. I did see that once I was able to read the documentation. I was initially put off on that idea because the itertools functions don't invoke a generator's close function. The itertools package assumes that all objects are only iterable and just have a next() method. Brock observed that as long as we make the calling convention explicit, we can probably get away with using close() instead of a more complicated approach. The existing callers of remote_search() chain the results and iterate through all of them. This will work by default. It's only if we get a fancy caller of remote_search() that we'll need to worry about the locking issues. If we force those callers to close each generator before invoking the next, then that should be sufficient. Since you and Brock seem to be in agreement about this approach, I'll pull the existing locking out of remote search and put it in a generator of a generator wrapper that we discussed earlier. I hope to have a new webrev for that out before too long. Thanks to both you and Brock for being patient while I got my head around all of the issues here. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
