2010.06.17 15:39 "[Tiff] libtiff 4 API/ABI stability?", by Adam Goode

2010.06.18 02:00 "Re: [Tiff] libtiff 4 API/ABI stability?", by Adam Goode

On 06/17/2010 09:54 PM, Olivier Paquet wrote:

That's fine for most operations but at some point (eg. file I/O if it is not memory mapped) we will need synchronization. Which pretty much means linking with pthread. This is why I raised the question: should we do it now or wait until is is actually needed?

For file I/O there are 2 lock-free solutions. The first is dumb but works well in practice: do an open/read/close cycle every single time you read. I have found that open/close is quite efficient and doesn't even register on my kernel profiles that I do for OpenSlide. This is totally thread safe.

The second solution is to employ FILE_FLAG_OVERLAPPED on Windows, or pread/pwrite on posix. This is an alternate interface to read or write that takes the offset in the call, making file I/O thread safe without even the slight overhead of open/close.

So with these solutions, I suggest that we don't add threading to libtiff yet, especially since the interface on Windows is different from pthread.