[gdal-dev] Call for review on RFC 101: Raster dataset read-only thread-safety

Laurențiu Nicola lnicola at dend.ro
Sat Sep 7 23:15:55 PDT 2024


On Sat, Sep 7, 2024, at 17:49, Even Rouault via gdal-dev wrote:
> It could be argued that coding it in C wouldn't be the best idea. I've spotted a TIFF Rust library (https://github.com/image-rs/image-tiff) but it is functionally limited (at least in terms of supported codecs. didn't check thourougly) and also associates the TIFF "object" with a file reader with read+seek capabilities, and thus methods like read_chunk() (https://github.com/image-rs/image-tiff/blob/6dc7a266d30291db1e706c8133357931f9e2a053/src/decoder/mod.rs#L1012) take a mutable self reference, making it incompatible of thread-safety.
I think there are two aspects to this:

 - few image Rust libraries are going to be as battle-hardened as libtiff. People just started working on competing implementations because they had a need or they wanted to, but didn't implement any advanced features, or they moved on to other projects. I think tiff, for example, doesn't support writing tiled images [1]. The API is just what happened to be required, but it can still change, more easily than that of libtiff [2]
 - however, the decoder is generic over the input stream, so it can be used even today with a pread/mmap wrapper over a reference-counted file handle (you could point multiple decoders to the same file)

Laurentiu

[1] https://github.com/image-rs/image-tiff/issues/205
[2] the Rust community is more tolerant of breaking changes because the tooling makes them less of a problem
[3] https://docs.rs/tiff/latest/tiff/decoder/struct.Decoder.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240908/8f40d039/attachment.htm>


More information about the gdal-dev mailing list