#318 Global lock in png.c downgrade multithreads performance

[Yuhan Guo]

We are using GraphicsMagick-1.3.21 version to do image processing. We found our program not picking up CPU usage even when load is high, and requests just keep piling up.

We noticed that there is a png_semaphore in coders/png.c. And it serializes ReadOnePNGImage and WriteOnePNGImage calls in our multithreading environment. Which basically becomes the bottleneck of our program.

I noticed that this lock is just for setjmp/longjmp to handle exceptions, and these calls are tricky and not necessarily thread-safe. Is there a way to get around with that?

Thank you in advance!

[Bob Friesenhahn]

This issue was fixed in the 1.3.27 release:

• JPEG/PNG: The SETJMP_IS_THREAD_SAFE definition is used to determine
  if setjmp/longjmp are thread safe. If these interfaces are thread
  safe, then concurrent reads/writes are possible. This definition is
  false for Solaris but true for Linux. JPEG and PNG will be fully
  concurrent if this definition is enabled.