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