¿Qué es seguro para subprocesos o seguro para subprocesos en PHP?




multithreading thread-safety (3)

Se necesitan antecedentes sobre los enfoques de concurrencia:

Diferentes servidores web implementan diferentes técnicas para manejar las solicitudes HTTP entrantes en paralelo. Una técnica bastante popular es el uso de subprocesos, es decir, el servidor web creará / dedicará un único subproceso para cada solicitud entrante. El servidor web HTTP Apache admite varios modelos para manejar solicitudes, uno de los cuales (llamado MPM del trabajador) usa subprocesos. Pero es compatible con otro modelo de concurrencia denominado prefork MPM que utiliza procesos, es decir, el servidor web creará / dedicará un proceso único para cada solicitud.

También hay otros modelos de concurrencia completamente diferentes (que usan sockets asíncronos y E / S), así como otros que mezclan dos o incluso tres modelos juntos. Para responder a esta pregunta, solo nos interesan los dos modelos anteriores y tomamos el servidor HTTP Apache como ejemplo.

Se necesitan antecedentes sobre cómo PHP se "integra" con los servidores web:

PHP en sí no responde a las solicitudes HTTP reales: este es el trabajo del servidor web. Así que configuramos el servidor web para reenviar las solicitudes a PHP para su procesamiento, luego recibimos el resultado y lo enviamos de vuelta al usuario. Hay varias formas de encadenar el servidor web con PHP. Para el servidor HTTP Apache, el más popular es "mod_php". Este módulo es en realidad PHP en sí mismo, pero se compila como un módulo para el servidor web, por lo que se carga directamente en él.

Existen otros métodos para encadenar PHP con Apache y otros servidores web, pero mod_php es el más popular y también servirá para responder a su pregunta.

Es posible que no haya necesitado entender estos detalles anteriormente, ya que las empresas de alojamiento y las distribuciones de GNU / Linux vienen con todo lo preparado para nosotros.

Ahora, en tu pregunta!

Dado que con mod_php, PHP se carga directamente en Apache, si Apache va a manejar la concurrencia usando su MPM Worker (es decir, usando Threads), entonces PHP debe poder operar dentro de este mismo entorno de múltiples hilos, lo que significa que PHP debe ¡Sea seguro para los hilos de poder jugar la pelota correctamente con Apache!

En este punto, debería estar pensando "OK, así que si estoy usando un servidor web de múltiples hilos y voy a incrustar PHP directamente en él, entonces debo usar la versión segura de subprocesos de PHP". Y esto sería correcto pensar. Sin embargo, como sucede, la seguridad de subprocesos de PHP está muy disputada . Es un terreno de uso si realmente sabes lo que estás haciendo.

Notas finales

En caso de que se lo pregunte, mi consejo personal sería no usar PHP en un entorno de múltiples subprocesos si tiene la opción.

Hablando solo de entornos basados ​​en Unix, diría que, afortunadamente, solo tienes que pensar en esto si vas a usar PHP con el servidor web Apache, en cuyo caso se recomienda utilizar el MPM prefork de Apache (que no utiliza subprocesos y, por lo tanto, no importa la seguridad de subprocesos de PHP) y todas las distribuciones de GNU / Linux que conozco tomarán esa decisión por usted cuando instale Apache + PHP a través de su sistema de paquetes, sin siquiera preguntarle para una elección Si va a utilizar otros servidores web como nginx o lighttpd , no tendrá la opción de incrustar PHP en ellos de todos modos. FastCGI uso de FastCGI o algo similar que funciona en un modelo diferente donde PHP está totalmente fuera del servidor web con múltiples procesos PHP utilizados para responder solicitudes a través de, por ejemplo, FastCGI. Para tales casos, la seguridad del hilo tampoco importa. Para ver qué versión está usando su sitio web, coloque un archivo que contenga <?php phpinfo(); ?> <?php phpinfo(); ?> en su sitio y busque la entrada de la Server API del Server API . Esto podría decir algo como CGI/FastCGI o Apache 2.0 Handler .

Si también observa la versión de línea de comandos de PHP, la seguridad de los subprocesos no importa.

Finalmente, si la seguridad de los subprocesos no importa, ¿qué versión debería utilizar: la seguridad de subprocesos o la no segura de subprocesos? Francamente, no tengo una respuesta científica! Pero supongo que la versión no segura para subprocesos es más rápida y / o menos con errores, o de lo contrario hubieran ofrecido la versión segura para subprocesos y no se molestaron en darnos la opción.

Vi diferentes binarios para PHP, como sin hilos o sin hilos. ¿Qué significa esto? ¿Cuál es la diferencia entre estos paquetes?


Para mí, siempre elijo una versión segura sin subprocesos porque siempre uso nginx o ejecuto PHP desde la línea de comandos.

La versión segura sin subprocesos debe usarse si instala PHP como un binario CGI, una interfaz de línea de comandos u otro entorno donde solo se usa un solo subproceso.

Se debe usar una versión segura para subprocesos si instala PHP como un módulo de Apache en un MPM de trabajo (modelo de multiprocesamiento) u otro entorno donde se ejecutan simultáneamente varios subprocesos de PHP.


Según la documentación de PHP ,

¿Qué significa la seguridad de subprocesos al descargar PHP?

Seguridad de subprocesos significa que el binario puede funcionar en un contexto de servidor web multiproceso, como Apache 2 en Windows. Thread Safety funciona creando una copia de almacenamiento local en cada subproceso, de modo que los datos no colisionen con otro subproceso.

Entonces, ¿qué elijo? Si elige ejecutar PHP como un binario CGI, entonces no necesitará seguridad de subprocesos, ya que el binario se invoca en cada solicitud. Para los servidores web de multiproceso, como IIS5 e IIS6, debe usar la versión de PHP con hilos.

Las siguientes bibliotecas no son seguras para subprocesos. No se recomiendan para su uso en un entorno de subprocesos múltiples.

  • SNMP (Unix)
  • mSQL (Unix)
  • IMAP (Win / Unix)
  • Sybase-CT (Linux, libc5)




threadcontext