Re: libjpeg thread safe constraint is not must

Since GM is running on centos 7 in our case, and man pages clearly document setjmp() and longjmp() are thread safety:

       │Interface               │ Attribute     │ Value   │
       ├────────────────────────┼───────────────┼─────────┤
       │setjmp(), sigsetjmp()   │ Thread safety │ MT-Safe │
       ├────────────────────────┼───────────────┼─────────┤
       │longjmp(), siglongjmp() │ Thread safety │ MT-Safe │
       └────────────────────────┴───────────────┴─────────┘
http://man7.org/linux/man-pages/man3/setjmp.3.html

Does this mean we can use multi-thread for JPEG images on centos 7? 

I also note that setjmp/longjmp are also used in PNG err handle, and GM let user confirm and define a SETJMP_IS_THREAD_SAFE flag to open multi-thread feature. If core of the problem is not libjpeg itself but thread safety of setjmp/longjpm as you said, could GM use the same flag for JPEG multi-thread? 


-----邮件原件-----
发件人: Bob Friesenhahn [mailto:[email protected]] 
发送时间: 2017年7月31日 21:31
收件人: GLENN PEHRSON <[email protected]>; Requests for help with GraphicsMagick <[email protected]>
主题: Re: [GM-help] libjpeg thread safe constraint is not must

On Fri, 28 Jul 2017, GLENN PEHRSON wrote:

> I don't think we could arbitrarily declare that libjpeg is thread-safe.
> However, we could allow users to do that the same way they can declare 
> that libpng is thread-safe, by setting a compiler flag, 
> SETJMP_IS_THREAD_SAFE. (I am assuming that the only reason we have 
> made libjpeg thread-unsafe is because it uses setjmp()).
>
> It wouldn't take much coding to put appropriate #ifdef 
> SETJMP_IS_THREAD_SAFE tests in coders/jpeg.c; Bob, would you like me 
> to attempt that? And do you remember other reasons libjpeg has been declared unsafe?

Libjpeg itself is not the problem.  The problem is entirely due to use of setjmp/longjmp as the exception handling approach in GM code.

We know that at least Solaris (one of the few OSs which does document interface thread safety) documents that these interfaces are not thread safe.  Some research is required to determine if they are thread safe on other OSs.

On a multi-core system, it is possible (even likely) for the thread which makes the setjmp/longjmp to be scheduled on a different core between the setjmp and the longjmp and the processor/thread state restored by longjmp may not be valid for the different core.  I think that this may be a key point related to thread safety.  ANSI C does not address thread safety but one can safely assume that if a program is single-threaded that setjmp/longjmp will work reliably.

Bob
--
Bob Friesenhahn
[email protected], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________
Graphicsmagick-help mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/graphicsmagick-help
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Graphicsmagick-help mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/graphicsmagick-help