On 26/07/2013 18:12, Richard Hughes wrote:
> 2. There's no void *user_data to cmsSetLogErrorHandler
The cmsContext is passed to every call to cmsSignalError (well, almost
every - There are a couple of calls where 0 is passed as the context).
> 2 is a lot harder and a lot
> more important. If you're doing any kind of activity in the error
> callback, e.g. writing to a file, or writing a GError higher up the
> callchain you need to be able to pass in arbitrary data to the log
> handler *without* using global static variables.
The cmsContext was introduced a while ago as a way to give *some* thread
safety to lcms. It is by no means a perfect system (as having 2 separate
apps calling into the same lcms library will conflict over their global
settings (*)), but it does solve the problem you are describing.
> The way I can see
> this working is something like this:
>
> static void
> colord_log_handler_cb (cmsContext ContextID, cmsUInt32Number
> ErrorCode, const char *Text, void *user_data)
> {
> CdLog *log = CD_LOG (user_data);
> cd_log_example (log, "lcms2 went fubar");
> }
>
> cmsSetLogErrorHandler2(colord_log_handler_cb, priv->logger);
But we already have this (effectively).
cmsSetLogErrorHandler takes a function pointer. The first argument to
this function pointer is a cmsContext. This cmsContext is passed into
cms on various different calls (see the ones ending in 'THR').
With your suggested change you'd get to set a void * when you set the
error handler, and you'd always get that same value back.
With what the code does currently you get to set a void * when you call
into lcms and any errors get that same value back. This is more powerful
as it lets you have a different void * in every thread that is calling
into lcms.
Robin
* LCMS still uses static globals to hold things like the alloc function
pointers, the alarm values, the currently registered plugins etc. I have
spent some time over the past week or so updating my own local copy of
LCMS so that these are held in a 'globals' struct and adding a new layer
of API that allows completely different instances of lcms to be used.
The code is actually turning out quite nicely, apart from the backward
compatibility requirements. Anyone interested can see the changes to the
version of lcms2 in the middle of the gs source tree here:
http://git.ghostscript.com/?p=user/robin/ghostpdl.git/.git;a=commitdiff;h=dad10f8a5fa2616625368fa2fbe4fb0bca09e4ea
The changes are not finished, so treat them with caution, but you should
get a flavour for what I am doing by looking at the APIs.
Stripping out the backward compatibility requirement and doing an lcms3
would give a much nicer codebase - but would users of the library be
prepared to accept this?
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user
