php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #71302 Undesirable, uncontrollable multithreading
Submitted: 2016-01-07 11:52 UTC Modified: 2016-01-07 13:57 UTC
From: p dot gackiewicz at intertele dot pl Assigned:
Status: Not a bug Package: imagick (PECL)
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: p dot gackiewicz at intertele dot pl
New email:
PHP Version: OS:

 

 [2016-01-07 11:52 UTC] p dot gackiewicz at intertele dot pl 
Description:
------------
imagick PECL extension does not set any resource limits at module init stage.
It does not allow to control these limits in configuration.

A problem arises, when PHP multi-threading is not desirable:
single-threaded, multi-process PHP installations (i.e. FastCGI, FPM), with
limited process number resources (i.e. multiuser PHP hosting).

Single Imagick call spawns PHP threads, which are not destroyed after use. They live untill PHP process death, unusable, but accounted into process resource limits.

We need new PHP ini settings to allow administration control of thread limits (at least).

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2016-01-07 13:57 UTC] danack@php.net
-Status: Open +Status: Not a bug
 [2016-01-07 13:57 UTC] danack@php.net 
> We need new PHP ini settings to allow administration control of thread limits

ImageMagick allows you to control the number of threads used via the policy.xml or you can completely disable threading by compiling ImageMagick with the `--disable-openmp` flag set.

> Single Imagick call spawns PHP threads,

Technically ImageMagick spawns it's own threads. Imagick doesn't actually spawn them.

> i.e. multiuser PHP hosting

Imagick probably isn't safe to use in this scenario anyway. I would recommend switching to virtual private servers, rather than using shared hosting.
 [2016-01-07 14:32 UTC] p dot gackiewicz at intertele dot pl 
> ImageMagick allows you to control the number of threads used via the policy.xml or you can completely disable threading by compiling ImageMagick with the `--disable-openmp` flag set.

ImageMagick does read policy.xml. Imagick - does not, I have confirmed it with strace (v. 3.4.0RC4). Imagick ignores environment settings (MAGICK_THREAD_LIMIT, OMP_THREAD_LIMIT) too.
Maybe Imagick lacks some init call?
Recompiling ImageMagick because of small Imagick flaw is hmmm, a bit strange.

> Technically ImageMagick spawns it's own threads. Imagick doesn't actually spawn them.

You are correct, my statement was innacurate, I have ment ImageMagick.

> Imagick probably isn't safe to use in this scenario anyway. I would recommend switching to virtual private servers, rather than using shared hosting.

Hmm, very enlightening. ImageMagick/Imagick is so unsecure as any other PHP element, I believe.
But this is not a subject of this discussion.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri May 17 02:01:32 2024 UTC