Re: libjpeg thread safe constraint is not must

On Tue, 1 Aug 2017, yzh杨振宏 wrote:

> 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?


Yes.

While GraphicsMagick itself does not use signal masks, the failure to 
restore signal masks in longjmp() could be an issue if it is used as a 
library, depending on how the whole program is using signals and 
signal masks.  Signal masks apply to the whole program.


> 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?

That would be a good idea.  A good approach is to add a definition 
which is updated by the configure script and which defaults to the 
assumption of thread-safe and only disables it for platforms known to 
be not thread safe.

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