2010.06.18 13:54 "Re: [Tiff] libtiff 4 API/ABI stability?", by Olivier Paquet

On Thu, Jun 17, 2010 at 10:00 PM, Adam Goode <adam@spicenitz.org> wrote:

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.

This sounds like it would be horrible on some network file systems, involving many more round trips than necessary (essentially doing synchronization through the remote server).

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.

This appears much better.

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.

It is... but so is the interface for your I/O solution. This fix is also specific to I/O (other issues might pop up) and would probably need to break the ABI (TIFFClientOpen). It remains a good approach though.

Anyway, I don't like the idea of pulling in pthread either, I was simply pointing out that we might unfortunately need it at some point if we are to have more advanced support for multiple threads. We can certainly fix current issues without it and avoid it for a long time. Everyone seems ok with that.

Olivier