Re: libjpeg thread safe constraint is not must
Bob Friesenhahn <[email protected]>
| Newsgroups | gmane.comp.video.graphicsmagick.help |
|---|---|
| Message-ID | <[email protected]> |
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