On Mon, Jan 25, 2010 at 04:19:03PM -0600, Shawn Walker wrote: > No, this will not cause all results to be held in memory (simple > tests of generators of generators with print statements show this). > However, after reading section 5.2.8 of python's expressions doc, I > think we're sort of stuck here (see above).
At the moment, there seems to be connectivity problems for networks that are off SWAN. I'll try to take a look at the expressions doc whenever we get internet access back. In the mean time, I think there is a solution, but it has some tradeoffs that aren't espeically palatable. Instead of returning a generator function, remote_search should return an object that's iterable. The object will cache some number of search results, but not so many that takes up a lot of memory. Iterating over the object will produce the same results that remote_search() does now, but when the object runs out of cached results it will have to go to the transport and request more data to fill its buffer. This object will hold a reference to the API and will only be cancelable when it's holding the activity lock which is when it's downloading additional search results. This is less than ideal because: a. We're switching can_be_canceled on and off as the object holds and releases the locks. b. We're caching search results in memory, but we can bound the result size. c. The GUI will only be able to cancel a search through the API when it's filling its buffer. They'll need to change their current search code to have a GUI specific variable that determines whether the search that is in progress was cancelled, since the API will only be locked for some portion of the time a remote search occurs. However, I don't see any better approach. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
