2016.07.05 15:41 "Re: [Tiff] Proposed API improvements", by Bob Friesenhahn
2016-07-05 5:41 GMT-04:00 Yakov Galka <firstname.lastname@example.org>:
that others will benefit if this makes it into libtiff. Since libtiff can extend the behavior of its APIs, we can change the TIFFTileXXX interface to support reading strips rather than introducing new API like I did. The only
That appears to make sense. We have something similar in our code, where the layer calling TIFF functions handles strips as wide tiles and presents a single interface to the rest of the application. That it can be done with the existing tile interface makes it an obvious improvement.
Historically, a problem has been that applications support reading scanlines or strips but fail to offer code to read tiles. A new tile-oriented interface would represent a third case which no applications would support when it is introduced. A concern would be that most using applications are already written, existing applications still need to work with many existing libtiff versions, and so the new interface would not be used.
I think fixing the error handling is important as it really is broken. I'm more neutral on the tile/strip situation.
In addition to ordinary multi-thread issues, a problem which has been reported to me is that some users of GraphicsMagick are also directly or indirectly using libtiff in other ways and in different threads. The problem here is that the registered error reporting functions are being overwritten by different active requestors, and so there are spurious crashes.
The error reporting functions should be supplied as arguments to TIFFClientOpen() (and friends) as well as any necessary context to pass on to those functions. There is the possibility of using thread specific data to avoid this approach, but this assumes that the thread which registers the error callbacks is the same as will be later using libtiff functions which need to call this error handler. I have some thread specific data API wrappers in GraphicsMagick which work well with POSIX threads, Windows threads, and no threads, and I could contribute this to libtiff.
If libtiff needs to be compiled with knowledge of a threading model, then problems might result if an application wants to use it which uses a different threading model. There are also linkage consequences.
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/