[gdal-dev] Race condition between forked processes with opened Tiff dataset on Linux
Even Rouault
even.rouault at spatialys.com
Thu Dec 14 10:07:24 PST 2017
Jiri,
I'm not sure to which extent we want to support the fork() situation, as there are perhaps
situations where that wouldn't work for some reason, but as something experimental why
not.
Regarding the way file closing is done in VSIUnixStdioHandle, I think that instead of relying
on ferror(), fclose() should be just called and fp nullified, and you would test that in Seek(),
Read(), Write() etc to know if you must reopen the file
Another option would be to put that reopening logic at the driver level, but your option is
probably better if we wanted to extend that to other drivers.
Actually I'm thinking to yet another option where things would work even without an explicit
config option. VSIUnixStdioHandle could keep the getpid() active at opening time, and check
before each access if it has changed, in which case it would open a fresh handle (assuming
the getpid() cost is neglectable. not completely sure of that for drivers that do 1 byte per 1
byte read where the buffering logic of file streams avoids doing one system call each time...
Looking at the manpage of getpid(), there used to be a time where glibc did a buffering of
the getpid() result, but this was eventually removed because bug prone, so now a glibc
getpid() translates into a system call)
In any case, we would definitely need an explicit test in autotest/cpp for that new capability
Even
--
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20171214/fde71b0d/attachment.html>
More information about the gdal-dev
mailing list