[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