2004.08.29 10:26 "Re: [Tiff] tif_fd and error handling", by Joris Van Damme

I agree with Erik Corry's (and Joris's) opinion. Any asynchronous error reporter should pass user supplied context.

However, not all hope is lost. Multithread environments normally provide the means to obtain the current thread ID. As long as the per-thread context is associated with the thread before libtiff is called, then the current thread ID may be used to retrieve it within the warning/error handler.

The problem is not limited to multi-thread apps, or, from the other point of view, the number of 'contexts' does not need to be limited to one per thread.

Consider an image class. To be conviniently used, such a class could be designed to:

• contain its own error status
• expose that error status to the application
• ignore all calls of the application once an error status has been set

That could be so to allow convinient application usage like the following pseudocode

create an image object
call upon that object to load a tiff file
call upon that object to retrieve width in var x
call upon that object to retrieve height in var y
now check error status of object, if error then
    yadayada with error message to be retrieved from object
else
    blabla with valid x and y

This is just one example of course, and I don't think I really needed to go into so much details. It's probably true that just any design of an image class, or whatever kind of layer that sits between a codec like LibTiff and the application, needs to associate generated error messages with a particular 'context' which is not necessarilly unique or unique per thread.

Same goes for warnings. Such an image class, or whatever is in the layer in-between, needs to also present some functional equivalent of a warning message list. But again, how to know what image object the warning belongs to, inside the warning handler that receives no clue like TIFF*, clientdata, or fd?

Your solution does hold when the design is such that every image object get alloted its own worker thread, and as such, every thread has exactly one 'tiff context'. I don't know about Unix, but in the windows environment it could be implemented with something as simple as a threadvar, or, as you say, any means to associate thread ID with TIFF context.

Bottom-line: yes, the current system is sufficient, not only in unix-command-line-fixed-known-contexts situations, but also in the single-context-per-thread situation, I agree. But there is no way it can be sufficient in the most common situation where there is a flexible set of contexts per thread, which must be the case for most imaging layers, and necessarilly is the case for the most simple single-threaded imaging layers even.

Joris Van Damme
info@awaresystems.be
http://www.awaresystems.be
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html