[Qgis-developer] New API for access to vector features

[Marco Hugentobler]

Hi Martin

I'm not familiar with the grass libraries. Is it possible to iterate 
simultaneously from several threads or do the grass libs apply a lock?

Maybe the GRASS experts on the mailing list could help us there.

Regards,
Marco

>But the good news is that
> most (if not all) of the current providers could be altered to allow
> simultaneous access from threads. So far I don't know how this would
> be handled in grass provider




> Am Montag, 5. Juli 2010, um 11.29:12 schrieb Martin Dobias:
> On Mon, Jul 5, 2010 at 10:19 AM, Marco Hugentobler
> 
> <marco.hugentobler at sourcepole.ch> wrote:
> > Hi Martin
> > 
> > Thank you for this detailed description. I agree with you that the
> > iterator pattern is a good solution for concurrent vector layer access.
> > I encountered problems with concurrency a lot of times, e.g. in the
> > print composer and in the analysis methods. So I will be happy once I
> > can remove the workarounds for them.
> > 
> >> Which approach will be used can be
> >> decided at the level of each provider, so if some providers don't
> >> support concurrent access at all (or the implementation would be too
> >> complicated), we can stick with the use of locking.
> > 
> > Note that there are also a number of situations (especially in vector
> > analysis) where we could have conflicts within the same thread. E.g. if
> > calculating inverse distance interpolation, we need, for each point,
> > calculate the distance to all other points. It would be convenient to
> > use two iterators on the same layer for it, which would probably create
> > a dead lock if using locking in providers
> > (currently it's even worse, we store all the points in memory for IDW
> > calculation).
> > Maybe we should declare concurrent access mandatory for 2.0 providers?
> 
> I was thinking about this. Having the possibility of simultaneous
> access for all providers would be indeed nice, though I'm not sure how
> feasible it would be: if the provider's backend has API that is not
> reentrant (e.g. it uses static variables), there isn't probably much
> we could do with in, only to use locking. But the good news is that
> most (if not all) of the current providers could be altered to allow
> simultaneous access from threads. So far I don't know how this would
> be handled in grass provider, and maybe there could be problems with
> some obscure OGR drivers.
> 
> > An interesting point if implementing concurrent access without locking
> > would probably be the implementation of robust iterators (if provider is
> > edited while iterators are open). Maybe something for 2.0...
> 
> The importance of robust iterators for vector layers / providers is
> questionable. I understand they can be important for data structures
> such as lists or vectors where the editing operations appear
> frequently. They also come at some price (cpu and memory). In vector
> layers and providers where the editing takes place just rarely, it's
> probably not worth the effort to implement them - read-write locks can
> take care of that. Anyway, it's not a common situation where a layer /
> data provider would be modified while features are being read.
> 
> Bye
> Martin


-- 
Dr. Marco Hugentobler
Sourcepole -  Linux & Open Source Solutions
Webereistrasse 66, 8134 Adliswil, Switzerland
marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee