[Qgis-developer] Merging of incompatible changes

Martin Dobias wonder.sk at gmail.com
Thu Oct 25 04:52:51 PDT 2012


On Thu, Oct 25, 2012 at 12:30 PM, Matthias Kuhn <matthias.kuhn at gmx.ch> wrote:
> How does the new API handle this?

There is an iterator class that you would use like this:

QgsFeatureIterator it = layer.getFeatures(request)
while (it.nextFeature(f)) { do_something; }

The constructor typically acquires a lock, when the iterator gets out
of scope, its destructor calls close() so the lock is released.

In python you could use just this:

while f in layer.getFeatures(request): do_something

> Is there only one iterator at the same time allowed which has to be
> released to allow another iterator on the same object?

Yes, with the current design only one thread (iterator) can read
particular data at the same time.

> In this case it truly is a problem. I imagined parallel iterators, where
> update could just claim another iterator and not care if anything else
> is iterating on the same provider. Although it's probably a considerable
> higher amount of work to implement this on all data providers.

This is where I would like to get in future. But as you noted this
approach needs greater amount of updates in providers:
- claiming another iterator means establishment of a new connection to
the resource (file, db/web connection)
- necessity to keep a pool of connections (to avoid the overhead of
establishing new connections) and cleaning of the pool when idle to
save resources
- make sure that modifications happen only when no iterators are active
- ...
But these are really things related just to internals of providers, so
no API changes will be necessary. In any case, this is not crucial for
rendering as usually there aren't concurrent requests for data (from
other parts of QGIS) while rendering - but if they are, they need to
be solved somehow - hence the locking mechanism.

Martin


More information about the Qgis-developer mailing list