2016.01.26 13:45 "Re: [Tiff] OpenMP enabled libtiff", by Aaron Boxer
Thanks, everyone. It will take me a little time to fully grok all of this information.
Sounds like the simplest approach is to allow the user to set a lock callback method,
which, if not null, will protect the global/static variables with a lock of the user's choice.
I don't think the user could use OpenMP for this, since OpenMP is a fork/join architecture. So,
it would also be nice to provide a light-weight cross platform lock library, wrapping pthreads / win32 API.
This idea of "blasting" the entire file into RAM, and then reading with libtiff; is this currently possible? Can
libtiff read from a memory buffer?
On Tue, Jan 26, 2016 at 4:12 AM, <firstname.lastname@example.org> wrote:
On 25 January 2016 at 18:25, Aaron Boxer <email@example.com> wrote:
Is anyone interested in having OpenMP support in libtiff?
Is this feasible? I am planning on adding this feature for another project I am working on, so I am trying to gauge interest.
I think I would not add openmp support directly. Scattered reads and writes are too difficult to support efficiently with the current structure.
Instead, as Bob said, I think I would split the library in two. Have a very low level interface which just reads or writes compressed strips or tiles, essentially just a thin wrapper around the read() and write() system calls, and then have a higher layer to do compression, decompression, packing and unpacking. The low-level read/write layer should be single-threaded, the higher layer should be threadsafe.
Now you can serialize read/write to match the disc structure, but the application can use SMP in whatever framework it prefers to accelerate the CPU-intensive parts.
Uncompressed tiffs already work rather like this: if you call TIFFReadEncodedStrip() on an uncompressed image, it's just a few function calls around read() --- it's very easy to saturate any disc system. We just need to move the decompress stage outside the serial code path.