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

[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