On Thu, Oct 25, 2012 at 9:25 AM, Matthias Kuhn <matthias.k...@gmx.ch> wrote: > Hi all, > > I don't know if somebody already brought up this (the discussion is > already rather long), but is there no possibility for including legacy > methods? > > For the iterators this would probably mean, that there is a reserved > iterator running single-threaded for any calls to the old API. > > I don't know what would be necessary to make a legacy string API.
In my GSoC 2010 work I have done exactly that thing: support old API backed by the new iterators. But it has proved to cause trouble when combined with locking - imagine this case: 1. a function calls layer.select(). The old API support will initialize an iterator and acquire a lock. 2. the function reads just one feature, then exits. Lock is still acquired by old API support, because it is not possible to tell whether some more features won't be fetched. If the function would 3. user triggers redraw of the canvas 4. renderer tries to acquire the lock... but it's still being held by old API support, so the rendering thread has to wait... indefinitely Normally if a function reads all data served from layer.select() that would be not a problem, because the lock would be freed. So this lead me to the decision that keeping old vector data fetching API is not an option. Martin _______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer