[Gdal-dev] GDAL reentrancy issue
szekerest at gmail.com
Mon Nov 20 17:00:22 EST 2006
2006/11/20, Marek Brudka <mbrudka at aster.pl>:
> It depends on the architecture of this web application. If the
> application is launched per HTTP connection (simple CGI) then it really
> doesn't matter if OGR is or is not thread safe. But if the application
> is a service with pool of threads or even with thread per connection
> model, then you should expect problems.
Yes, the latter is the case with the ASP.NET applications. Every
request might be
handled by different thread from a pool of threads within the host process
(ti w3wp.exe or aspnet_wp.exe).
> The simple patch is "one mutex to rule them all" (tm), namely before
> each call to the custom assembly you mentioned above the mutex should be
> locked. However, if you need more concurrent and really faster solution
> you should be prepared to modify OGR..
This kind of synchronization might be utilized at the SWIG interface
level only since
multiple application domains may exist within the same process.
There's not too much
chance to syncronize between application domains.
So in effect we could create a big lock to protect the global
variables from the multiple
simultaneous access by the different threads at the SWIG interface.
However this approach would highly degrade the performance of the application.
Alternatively you could create a set of multiple worker processes to
do the GDAL specific task in
the middleware and establish some kind of out of process communication
between the ASP.NET
application and worker processes.
More information about the Gdal-dev