Re: Read/WriteOnePNGImage has a global lock which affects multithreading efficiency

Bob Friesenhahn <[email protected]> Thu, 3 Sep 2015 08:57:23 -0500 (CDT)
Newsgroups gmane.comp.video.graphicsmagick.bugs
Message-ID <[email protected]>
  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---559023410-414673458-1441288643=:20098
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by blade.simplesystems.org
	id t83DvNBF006739

On Thu, 3 Sep 2015, Yuhan Guo wrote:

> Hi All,
>=20
> We are using=C2=A0GraphicsMagick-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 serial=
izes ReadOnePNGImage and WriteOnePNGImage calls in our
> multithreading environment. Which basically becomes the bottleneck of o=
ur program.
>=20
> I noticed that this lock is just for setjmp/longjmp to handle exception=
s, and these calls are tricky and not necessarily thread-safe.
> Is there a way to get around with that?

If you are able to compile from source code, it look like adding=20
CPPFLAGS=3D-DSETJMP_IS_THREAD_SAFE=3D1 as a configure option will disable=
=20
the locking.

For some reason the JPEG coder (also using setjmp/longjmp) does not=20
use semaphores.

The thread safety of setjmp/longjmp is not clear.  On some operating=20
systems, they are declared not to be thread safe while on others they=20
are assumed to be thread safe by users without any formal=20
documentation to support or deny it.

The Linux manual page advises that signal handling may be modified and=20
to use sigsetjmp() and siglongjmp(3) instead.  The Solaris manual page=20
includes warnings about signal handlers and pending signals and=20
declares that all of these functions are not thread safe.

GraphicsMagick does not schedule signals for itself but the C library=20
implementation might use signals, or an application linked with the=20
GraphicsMagick library may use signals.

I have an idea for a way to avoid setjmp/longjmp entirely on systems=20
supporting POSIX threads but have not implemented it yet.

Bob
--=20
Bob Friesenhahn
[email protected], http://www.simplesystems.org/users/bfriesen=
/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
---559023410-414673458-1441288643=:20098
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
---559023410-414673458-1441288643=:20098
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Graphicsmagick-bugs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/graphicsmagick-bugs

---559023410-414673458-1441288643=:20098--