My understanding is that longjmp() and setjmp() use thread-local
storage, so I don't know why they would be thread-unsafe on any modern
platform, as long as you are using a different jmp_buf for each thread.
The participants in the "discussions" you link to below seem to believe
that setjmp() is not thread-safe on any platform and that Solaris is the
only one telling the truth about it. I disagree with that assessment.
I think it's more likely that setjmp() is thread-safe on all modern
platforms, and Sun just didn't update their man page to reflect this
fact with Solaris 10. The man page for setjmp() in Solaris 10 dates to
2002, several years before Solaris 10 even existed. It wouldn't
surprise me if setjmp() was thread-unsafe with Solaris 8 or 9, but it
would be very surprising to me if that was still the case with S10 and
even more surprising if it was still the case with S11 (S11 is based on
OpenSolaris.)
If it is the case that setjmp() is thread-unsafe on Solaris, then that
falls into the category of "so not my problem."
On 12/31/11 7:31 AM, Daniel wrote:
> Thank you for your fast response, I deep a little more in the research.
>
> I see that libjpeg library is handled as not being thread safe in many
> libraries, and It seems that its related with the implementation of
> setjmp/longjmp in some environment, specifically in solaris.
>
> As I'm not using solaris environment nor sharing structs from the same
> JPEG between thread, this information is enough for me.
>
> It not easy to find more information on this matter, I found this thread
> on libpng maillist which have the same "problem"
> http://comments.gmane.org/gmane.comp.graphics.png.devel/2747
>
> Another nearly-flame part of the thread on this issue is here (read only
> if you have spare time :D)
> http://comments.gmane.org/gmane.comp.graphics.png.devel/2764
>
> It's not clear at all if even in solaris this calls are not thread safe.
> Seems to be that are thread safe as long as you do the setjmp and
> longjmp on the same thread, but thats pure speculation.
>
> Regards
> Daniel
>
> http://comments.gmane.org/gmane.comp.graphics.png.devel/2747
>
> On 30 December 2011 01:25, DRC <dco...@us...
> <mailto:dco...@us...>> wrote:
>
>
> On Dec 29, 2011, at 9:56 AM, Daniel <dp...@gm...
> <mailto:dp...@gm...>> wrote:
>
> > Hi guys,
> >
> > My question is, is libjpeg-turbo thread-safe?
> >
> > It seems that libjpeg is not fully thread safe due to the way it
> handles the errors.
> > I read some people saying this problem is solved on libjpeg-turbo,
> can someone confirm this?
>
> I'm not aware of anything we are doing differently than libjpeg
> vis-a-vis error handling. I'm not sure why libjpeg would be unsafe
> in that regard as long as you are using a separate JPEG
> compress/decompress structure for every thread. I will double check
> it, though.
>
>
>
>
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
>
>
>
> _______________________________________________
> Libjpeg-turbo-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-users
|
