Even,
that was really helpful. Finally, I solved it without any need to modify
GDAL.
I do the mmap() myself in my application. Then I create VSILFILE out of the
mmapped block by VSIFileFromMemBuffer().
I can then GDALOpen() the /vsimem/ file and fork freely.
The GTIFF_USE_MMAP is a cherry on th
> Can I assume that we are talking about opening for read and not for write ?
Yes, it's only for reading.
I've concluded eventually that I will try to use memory mapping.
Here is a post about memory mapping between Even and me I forgot to
resend to the mailing list:
> Dear Even,
>
> Thank you f
On Thu, 14 Dec 2017, Jiri Drbalek wrote:
Hello.
If a Linux process with opened Tiff dataset is forked, it is not possible
to read from the dataset concurrently in these forked processes, because
file offsets and other attributes of the opened Tiff file are shared
between those processes.
I'
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 ferro
Hello.
If a Linux process with opened Tiff dataset is forked, it is not possible
to read from the dataset concurrently in these forked processes, because
file offsets and other attributes of the opened Tiff file are shared
between those processes.
One solution would be to serialize calls to GDAL,
