PHP thread security: We can see that zend debuger has a non-thread-safe version to know that PHP has launched a non-thread-safe version. Previously, I knew nothing about non-thread security:
Another article seems to have something to do with FASTCGI.
This is a piece of text, but I don't understand it:
Php itself is thread-safe. A service process can securely support multiple request threads.
Some extensions do not comply
For example, in the extension of thread security, the definition of global variables is defined between macro ZEND_BEGIN_MODULE_GLOBALS and ZEND_END_MODULE_GLOBALS, instead of directly defining functions as common C programs. Extensions that require ZTS (Zend Thread Safe) support must include the TSRM. h header file and define the TSRMG macro value
In the extension that does not support thread security, it is simply considered that a service process has only one request in the active state, and there will be no conflict, then, the global variables can be initialized in the RINIT function (RINIT indicates the request starts) and logged out in RSHUTDOWN:
CODE: PHP_RINIT_FUNCTION (ext)
{
Counter = 0;
}
PHP_FUNCTION (ext)
{
RETURN_LONG (counter ++ );
}
This is a simple counter. As long as the request does not end, every time you call ext, counter auto-increment is triggered.
In a multi-threaded environment, this program will cause serious confusion and the counter will become erratic, because there is no way to predict the thread trigger and end sequence and time. This indicates that this extension is not thread-level security.
Multithreading: Apache 1.3 and Apache 2.0
If you have been using Apache and PHP for a while, you may have seen a warning in the installation documentation, saying, "Do not use Apache 2.0.x and PHP in the production environment, neither Unix nor Windows ". In the PHP 5.0.2 package on Windows, the warning information can be found in line 745th in the install.txt file. We need to understand what this problem is, so that we can decide whether to use Apache 2.0 or ibm http Server 2.0.
Apache 2.0 can be configured to run in two ways: using a thread or not using a thread. When running as a thread-based server, multiple threads in the server can be active and executed at the same time, and response information can be generated for multiple users at a time. Generally, this can improve the server's response capability and make better use of large hardware with multiple processors. But it also introduces a risk. Each software layer of a server call must be secure when multiple users call the software at the same time. Although the Web server itself, PHP interpreters, and PHP extensions are safe to call in this way, some PHP extensions use libraries written in other languages (such as C, these libraries are not all thread-safe.
On the Apache Web page, you can find a discussion about this issue, which provides some suggestions, for more information, see references.
In practice, many people will choose to avoid this problem, but adopt the following two methods: either using Apache 2.0 in single thread mode or using Apache 1.3, it always runs in single-threaded mode. Although there are other differences between Apache 1.3 and 2.0, for example, Apache 2.0 supports IPv6, the biggest difference so far is the thread problem, therefore, retaining the Apache 1.3 server is not as degraded as it sounds.
What is this problem in ibm http Server? IBM compiled ibm http Server from Apache 2.0 in the thread mode: this is faster, but may be insecure when non-thread-safe extensions are used. Because IBM does not issue source code at the same time, and both the thread mode and the thread mode are selected during compilation, as an end user, you cannot re-compile ibm http Server 2.0 in non-thread mode. However, at the time of writing this article, IBM is releasing an ibm http Server based on versions 2.0 and 1.3 at the same time, so that you can choose to use a single-threaded Server based on version 1.3.
This article from The CSDN blog, reproduced please indicate the source: http://blog.csdn.net/mynameisyoudi/archive/2008/10/07/3029496.aspx
