[Qgis-developer] Merging of incompatible changes

[Matthias Kuhn]

How does the new API handle this?

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

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.

Matthias

On Thu, 2012-10-25 at 11:48 +0200, Martin Dobias wrote:
> On Thu, Oct 25, 2012 at 9:25 AM, Matthias Kuhn <matthias.kuhn at 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