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
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
