On Wed, 17 Dec 2008, Guy K. Kloss wrote: > > Hmmm, if it were object oriented (e. g. C++) no callback would be necessary > anyways, as then just an exception could be thrown, that is managed through > the default exception handling mechanism. But if it were C++ code, it wouldn't > be as easy to wrap it to Python using ctypes ... (at least until ctypes > handles that fully).
But you are assuming that every issue that lcms reports should result in a fatal error to the operation. That is a bad assumption. For example, it may be desireable to report "out of gammut" conditions but continue on with the processing. > That's one of the problems with *any* callbacks. They don't "bite" at the > place of the code invocation, but rather within the callback function/method. True. > By a buffer, do you mean an error buffer passed by reference as an additional > parameter to the library calls? Yes. A function plus a buffer is about as object oriented as it gets in C. Actually, in C you would pass a pointer to a struct which contains a function pointer plus some data. > Yet another approach I could envison is to wrap every call to lcms into a > calling function, that acquires a lock, executes the lcms API call, inspects > for an error, and returns with an appropriate state after releasing the lock. > This way concurrency of the calls could be eliminated, while the rest of the > code can happily run in parallel. It's also a bit of a dirty trick, but it > might work. Since lcms is slow it would be nice to allow multiple threads to invoke it at once. In a multi-threaded situation, the callback problem can be handled via thread specific data. The callback deposits the error info into thread specific data and the using code checks that thread specific data for an error report when the lcms call returns. This is ugly but it does work and is more reliable for multi-threaded programs than setjmp. Bob ====================================== Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ Lcms-user mailing list Lcms-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lcms-user
