LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
November 2004
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2004.11.04 23:51 "Re: is libtiff thread-safe?", by Joris Van Damme
> Documenting that issue and suggesting that the callbacks contain a > mutex or critical section (if thread safety is an issue) might be a > good idea. I totally fail to see the connection between the lack of TIFF * parameter in the callbacks on the one hand, and multi-threading on the other. The callbacks are called in the same thread context as the call to LibTiff in which the error occured. There's no threading issue here. Of course, *if* you next want to eg post all errors into the singe main UI thread or something... but that's a) a trivial multi-threading issue, as in not specific to warning or error handlers and totally not specific to these particular handlers, b) it is an assumption that you would want to post all error feedback to another thread or do anything else with them that might involve synchronization issues, as one might as well wish to keep things in a single thread, like eg an encapsulating TIFF object being owned and maintained in a single thread that also stores a copy to the error description, and c) this whole threading issue has nothing to do with the only actual base problem of the error and warning handlers as they are today, the problem that makes it impossible to really build on these handlers for whatever purpose, being the lack of TIFF * indication. The lack of TIFF * means application cannot trace back to a particular thread, sure, it also means application cannot trace back to a particular encapsulating TIFF object, or a particular file, or whatever. It simply means application cannot trace back the context of the error, and that is an issue in any case beyond the single-app-single-TIFF situation. So why is this even raised in relation to multi-threading? It is an issue, sure, but it is not related. Put otherwise: sure, if you need to feed errors from different threads to a single thread, you'll need to do some synchronization thinking. On the totally other end of the universe, if you maintain a filename string that is accessed from different threads, you might need to do some trivial synchronization thinking too. If encoded data production (like eg reception over a socket) originates from one thread, and a secondary thread decodes, there is a need for some trivial synchronization thinking. There is no more intrinsic connection between the error handlers and multithreading, then there is between the filename maintanance and multithreading, or IO and multithreading. Ie, there is *no* specific error/warning handler issue when it comes to multithreading. There *is* a fundamental problem with current handlers, being that they don't have a clue what TIFF * they apply to, which impairs all sorts of building on from it. 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