Thread: [Lcms-user] Re: is LCMS thread safe?
An ICC-based CMM for color management
Brought to you by:
mm2
From: <ma...@li...> - 2002-03-05 09:17:34
|
Hi, I'm forwarding this to mailing list... could be interesting for someone else. > I have been looking through some of the LCMS code and it seems like it is > not > thread-safe. In particular I looked at > > cmsTakeProductName > cmsTakeProductDesc > cmsTakeProductInfo > > all of which have static chars defined that could cause threading issues. > Is there a particular reason why these are set as statics? What would > happen if I would just change that. Yes, you are right. Those functions are NOT thread safe, since they write to a static buffer. However, those functions are ment to be used on UI only. The transform code is thread safe with USE_C method. I did check on a multiprocessor machine and did work. And you can change them if wish so... I used the static buffer just for simplicity sake. Nothing prevents to use a buffer pointer as a parameter, for example. But please note that those functions would be very rarely used on separated threads. About the "nDoAbort". This is supposed to be a global setting. Probably a multithreaded application would replace whole error handling by its own. Is as easy as write repacements for cmsSignalError() and cmsErrorAction(). Regards, Martí Maria The little cms project http://www.littlecms.com ma...@li... ----- Original Message ----- From: "Dhiraj Kacker" <dk...@sh...> To: "'Martí Maria'" <ma...@li...> Sent: Tuesday, March 05, 2002 12:09 AM Subject: is LCMS thread safe? > Hi Marti, > > I have been looking through some of the LCMS code and it seems like it is > not > thread-safe. In particular I looked at > > cmsTakeProductName > cmsTakeProductDesc > cmsTakeProductInfo > > all of which have static chars defined that could cause threading issues. > Is there a particular reason why these are set as statics? What would > happen if I would just change that. > > Also in the error handling the gloabal variable "nDoAbort" is used making > that too risky to use with multiple threads. > > Thoughts? > > -Dhiraj > > |
From: <ma...@li...> - 2002-03-05 16:25:07
|
Hi, >cmscnvrt.c:static cmsCIEXYZ IlluminantD50 = {D50X, D50Y, D50Z}; >cmserr.c:static BOOL nDoAbort = LCMS_ERROR_ABORT; >cmsgmt.c: static WORD RGBblack[4] = { 0, 0, 0 }; >cmsgmt.c: static WORD RGBwhite[4] = { 0xffff, 0xffff, 0xffff }; >cmsgmt.c: static WORD CMYKblack[4] = { 0, 0, 0, 0xffff }; >cmsgmt.c: static WORD CMYKwhite[4] = { 0, 0, 0, 0 }; >cmsgmt.c: static WORD LABblack[4] = { 0, 0, 0 }; >cmsgmt.c: static WORD LABwhite[4] = { 0xFF00, 0x8000, 0x8000 }; >cmsgmt.c: static WORD Default[MAXCHANNELS]; All those are constants (read only) or global settings. > cmsintrp.c:static Fixed32 Cube[27]; This one should NOT be present on lcms1.08. >cmsio1.c:static size_t UsedSpace; >cmsio1.c: static icLut8 LUT8; >cmsio1.c: static icLut16 LUT16; Humm... again these are gone on 1.08. Are you using latest version? >cmsio1.c: static char Name[2048]; >cmsio1.c: static char Name[2048]; > cmsio1.c: static char Info[4096]; These are for info functions. As said these functions are meant to be used in UI, which is not willing to be used on separate thread. You could modify them if wish so, however. > cmsxform.c:static WORD AlarmR = 0x7fff, AlarmG = 0xfffe, AlarmB = 0x7fff; >cmsxform.c:static icTagSignature Device2PCS[] = {icSigAToB0Tag, /* Perceptual */ > cmsxform.c:static icTagSignature PCS2Device[] = {icSigBToA0Tag, /* Perceptual */ >cmsxform.c:static icTagSignature Preview[] = {icSigPreview0Tag, More constant tables or global settings. >is there anything to be concerned about LUT8, LUT16, Default[MAXCHANNELS], >Cube[27], and UsedSpace. >Thanks, The only suspicious one is 'UsedSpace', but this is used by the profile writting extensions, which are undocumented in ver 1.08 and only used by the profilers. Anyway, please make sure you are using 1.08, previous versions were not tested on multiple threads. LUT8 and LUT16 are fixed in 1.08 Regards, Marti. ----- Original Message ----- From: "Dhiraj Kacker" <dk...@sh...> To: "'Martí Maria'" <ma...@li...> Cc: "Russ Muzzolini" <ru...@sh...> Sent: Tuesday, March 05, 2002 12:34 PM Subject: RE: is LCMS thread safe? Thanks for the reply, Marti. Are there any other threading issues with LCMS (outside of the ones below)? I did a : "grep static *.c | awk '$2 != "" {print $0}'" in the lcms src dir and found : cmscnvrt.c:static cmsCIEXYZ IlluminantD50 = {D50X, D50Y, D50Z}; cmserr.c:static BOOL nDoAbort = LCMS_ERROR_ABORT; cmsgmt.c: static WORD RGBblack[4] = { 0, 0, 0 }; cmsgmt.c: static WORD RGBwhite[4] = { 0xffff, 0xffff, 0xffff }; cmsgmt.c: static WORD CMYKblack[4] = { 0, 0, 0, 0xffff }; cmsgmt.c: static WORD CMYKwhite[4] = { 0, 0, 0, 0 }; cmsgmt.c: static WORD LABblack[4] = { 0, 0, 0 }; cmsgmt.c: static WORD LABwhite[4] = { 0xFF00, 0x8000, 0x8000 }; cmsgmt.c: static WORD Default[MAXCHANNELS]; cmsintrp.c:static Fixed32 Cube[27]; cmsio1.c:static size_t UsedSpace; cmsio1.c: static icLut8 LUT8; cmsio1.c: static icLut16 LUT16; cmsio1.c: static char Name[2048]; cmsio1.c: static char Name[2048]; cmsio1.c: static char Info[4096]; cmsxform.c:static WORD AlarmR = 0x7fff, AlarmG = 0xfffe, AlarmB = 0x7fff; cmsxform.c:static icTagSignature Device2PCS[] = {icSigAToB0Tag, /* Perceptual */ cmsxform.c:static icTagSignature PCS2Device[] = {icSigBToA0Tag, /* Perceptual */ cmsxform.c:static icTagSignature Preview[] = {icSigPreview0Tag, is there anything to be concerned about LUT8, LUT16, Default[MAXCHANNELS], Cube[27], and UsedSpace. Thanks, -Dhiraj -----Original Message----- From: Martí Maria [mailto:ma...@li...] Sent: Tuesday, March 05, 2002 5:39 AM To: Dhiraj Kacker Cc: lcm...@li... Subject: Re: is LCMS thread safe? Hi, I'm forwarding this to mailing list... could be interesting for someone else. > I have been looking through some of the LCMS code and it seems like it is > not > thread-safe. In particular I looked at > > cmsTakeProductName > cmsTakeProductDesc > cmsTakeProductInfo > > all of which have static chars defined that could cause threading issues. > Is there a particular reason why these are set as statics? What would > happen if I would just change that. Yes, you are right. Those functions are NOT thread safe, since they write to a static buffer. However, those functions are ment to be used on UI only. The transform code is thread safe with USE_C method. I did check on a multiprocessor machine and did work. And you can change them if wish so... I used the static buffer just for simplicity sake. Nothing prevents to use a buffer pointer as a parameter, for example. But please note that those functions would be very rarely used on separated threads. About the "nDoAbort". This is supposed to be a global setting. Probably a multithreaded application would replace whole error handling by its own. Is as easy as write repacements for cmsSignalError() and cmsErrorAction(). Regards, Martí Maria The little cms project http://www.littlecms.com ma...@li... ----- Original Message ----- From: "Dhiraj Kacker" <dk...@sh...> To: "'Martí Maria'" <ma...@li...> Sent: Tuesday, March 05, 2002 12:09 AM Subject: is LCMS thread safe? > Hi Marti, > > I have been looking through some of the LCMS code and it seems like it is > not > thread-safe. In particular I looked at > > cmsTakeProductName > cmsTakeProductDesc > cmsTakeProductInfo > > all of which have static chars defined that could cause threading issues. > Is there a particular reason why these are set as statics? What would > happen if I would just change that. > > Also in the error handling the gloabal variable "nDoAbort" is used making > that too risky to use with multiple threads. > > Thoughts? > > -Dhiraj > > |