[Gdal-dev] Motion to Adopt RFC 16: OGR Thread Safety

[Tamas Szekeres]

> There wasn't to much discussion on this as far as I recall, which I take
> to mean no one has a problem with it.  So moving to formal vote so I can
> implement this coming week.
>

Frank,

For me personally it's quite difficult to think over all of the
aspects of the proposed changes and should dig into the code and see
what we are fighting against.

As reading the title of the RFC I could think we'd want to put all the
OGR core into a good shape from the aspect of the thread safety. But
later only, some of the methods were addressed.
I would rather like to see the problem itself instead of it's
consequences. For example it would be better to enumerate the global
resources (staic variables, handles etc.) we are focusing on, in
addition to the methods that may use them. It's not so easy for me  to
consider all of the potential problems without looking into the code
(not having implemented by me) and searching for the core issue
behind.

Generally I like the idea as the RFC that would keep away much of the
backward incompatible changes, however conceptionally I would prefer
maintaining the internal state/context (such as the reader state) at
the client if it is possible when thinking about the multithreading
compliance. (Which might not be so easy to implement)

If we have static variables (that cannot be eliminated) then using
locks around that is inevitable, definitely. It seems we want to push
these issues at the driver's level that might be reasonable, but some
kind of locking strategy should be enforced for the various driver
implementors to follow. For example we should somehow establish a
framework for using 'shared locks' for reading the data and 'exclusive
locks' when writing etc.

Programmatically declaring how a driver implements the thread safety
is a bit awkward for me. I don't think it's convenient for the caller
starting by calling TestCapability first and then switching to
different accessing scheme depending to the driver's threading
behaviour. This is what should be deaclared for example on a wiki page
instead.

I like the cloning approach as a by-pass solution, however the various
drivers should suffer hardly when implementing a feasible code behind
that. I would prefer to see some of the details in this RFC to be
mentioned, like

1. Which are the globals that might be eliminated (if any)
2. Which are the resources (variables, file handles, database
connections, handles etc.) that should be protected by locks
3. Desired locking implementation patterns to be implemented by the drivers.


Apologies for this undetailed response, as coming back from the
conference it's difficult for me to kill all the pending tasks
aggregated and focus on the more important problems ;-)


Best regards,

Tamas