2021.01.01 22:17 "Re: [Tiff] Multithreading support?", by Bob Friesenhahn

Another point to consider is error handling. Due to libtiff using an error handler routine rather than a returned error code, this complicates error handling.

I can imagine you can use e.g. thread-local storage to have a single global handler which can handle errors in multiple threads. But it’s already messy to tie synchronous callbacks to the specific call triggering the failure in a multithreaded system.

GraphicsMagick uses thread-local storage and a single global handler and it has not caused problems that I can see. It only works due to the thread reporting the issue being the thread which called into libtiff (1:1).

Worker threads still need to report to a common master and so error reports by multiple threads need to be coalesced somehow based on either common storage, or harvesting thread specific storage. This can be as simple as delivering an error report to the same storage locations under a lock. Typically this can easily be implemented by passing a pointer to where the error information should be stored. It is then up to the API user to decide if error information is thread specific, or shared.

If POSIX threads are used, then thread cancellation handlers can be implemented using pthread_cleanup_push() and pthread_cleanup_pop(). The worker thread can then execute pthread_exit() and pass a value when there is a problem. A manager thread would then harvest return value information.

Bob

Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt