AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
March 2017

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



Valid HTML 4.01!



Thread

2017.03.17 14:29 "TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Dinesh Iyer
2017.03.17 14:53 "Re: TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Bob Friesenhahn
2017.03.17 15:53 "Re: TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Dinesh Iyer
2017.03.17 16:07 "Re: TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Dinesh Iyer
2017.03.17 17:01 "Re: TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Dinesh Iyer
2017.03.17 17:06 "Re: TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Bob Friesenhahn
2017.03.17 17:19 "Re: TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Yakov Galka
2017.03.17 17:02 "Re: TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Bob Friesenhahn
2017.03.17 21:02 "Re: TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by <rleigh@codelibre.net>
2017.03.17 21:08 "Re: TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Bob Friesenhahn
2017.03.17 22:23 "Re: TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Roger Leigh
2017.03.17 22:40 "Re: TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Paavo Helde
2017.03.17 23:03 "Re: TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Bob Friesenhahn
2017.03.18 10:53 "Re: TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by Yakov Galka

2017.03.17 21:02 "Re: TIFFSetErrorHandler vs TIFFSetErrorHandlerExt", by <rleigh@codelibre.net>

On 2017-03-17 17:02, Bob Friesenhahn wrote:
> On Fri, 17 Mar 2017, Dinesh Iyer wrote:
> 
>> Thanks Bob.
>> 
>> If I understand you correctly, I cannot have multiple threads each 
>> with its
>> own handler throwing errors/warnings. i need to ensure that only one 
>> thread
>> does the error handling, am I correct?
> 
> You can only register one error handling function at a time.  The
> function will be called under the same context as the thread which
> encountered the problem.  Knowing that it is called under the same
> execution context can be very useful.
> 
>> As a follow up, do i have to set the client_data field with a pointer 
>> to my
>> class such that it is accessible in the callbacks?
> 
> The client_data is for you.  If you use TIFFClientOpen() then it is
> provided so that you can use it has a handle for I/O or other
> purposes (e.g. also for errors).
> 
> In GraphicsMagick I use TIFFSetErrorHandler()/TIFFSetWarningHandler()
> and I use thread-specific data (POSIX or Windows) to reconcile between
> the error callback data and what the thread was working on.  I don't
> use client_data for that purpose.  This approach works if there is
> just one thread which ever does libtiff operations for a given handle.
> 
> The reason for the approach in GraphicsMagick is that the
> implementation pre-dates the addition of TIFFSetErrorHandlerExt() and
> it also works for older libtiff.

Could I suggest a perhaps controversial but useful solution for handling 
errors, which might be worth your consideration.

If the libtiff core were to use a C++ TIFF class reporting errors via 
exceptions, it would be possible for this to be wrapped by the existing 
C API calling the C++ code in a try/catch block and reporting any thrown 
errors via the handlers.  Or direct use by C++ code without any of that 
overhead--it could use the C++ API directly with exceptions.  This would 
permit completely thread-safe use from C++, and it would also permit 
multiple C error handling strategies--either with the global handler as 
now, a per-TIFF handler or something completely different.  The C API 
could simply be a thin wrapper around the C++ core, and remain 100% 
backward compatible while also allowing direct use from C++ without 
wrapping the C code.

In the OME project I currently work on, we already have a fairly complex 
C++ wrapper around the C API.  It works, but due to the need to 
synchronise for the context-specific error handler, it's much more 
inefficient and complex than it would need to be were it native.  If 
using a C++ core would be something worth considering, it's likely I 
could dedicate some paid time to working on it, since it would replace a 
whole lot of wrapper code we already have to maintain.


Regards,
Roger