LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
February 2009
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
2009.02.17 21:36 "Re: Accessing tif->tif_clientdata within my own error andwarning functions", by Joris Van Damme
Philip, > Next question - It looks like the warning and error handling is not thread > safe. I guess that I would have to add function pointers to TIFF? "Thread safe" is such an over-simplification that I find it's actually a catch phrase without meaning when it does not come accompanied by an elaborate description of the threading situation you designed. If only one thread is working on a particular TIFF context, then things should be fine. There is no thread context switching or anything under the LibTiff hood, so the warnings and errors that trigger calls to your handlers should do so inside the thread context and all remains safe. I'd go as far as using the words thread-blind to describe LibTiff, if only that term existed, and such is a good starting point for thread-safe usage, as it is for continued thread-blind usage and single-thread usage also. If by "thread safe" you mean to say that you want things like having worker threads on the one hand calling LibTiff, and having the warning handlers do UI thread specific stuff like putting up a windows, then sure, you need synchronisation mechanisms exactly like you do with the decoders output when you decide to render it inside a UI. Probably appending rendering and warning output to protected objects shared with the UI thread, and posting messages to the UI thread signalling that data appending event, is one of the easiest and most common schemes. If by "not thread safe" you mean to say that there's a chance that the context pointed to by the tif->tif_clientdata is deleted/freed/invalidated before all work on the TIFF* object is done, thereby rendering it possible that the tif->tif_clientdata is an invalid pointer at the time your handler is called, then I'd say this is defenetly a design you should avoid. I wouldn't refer to the objects used as "not thread safe" in this case, but to the design as buggy. Use usage counters when you must, think of the TIFF* as strictly owned by the context pointed to by tif->tif_clientdata or whatever, but keep the context alive and the pointer to it unchanging as long as there's a valid TIFF* logically 'inside' it. But there's thirteen dozen other things you could mean with "thread safe". You'll have to elaborate if your question is answered already. Best regards, Joris