sigmasternchen/php-doc-en
1
0
Fork 0
mirror of https://github.com/sigmasternchen/php-doc-en synced 2025-03-15 16:38:54 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

tidy wording

Browse source 
git-svn-id: https://svn.php.net/repository/phpdoc/en/trunk@330044 c90b9560-bf6c-de11-be94-00142212c4b1
This commit is contained in:
Joe Watkins 2013-04-09 10:15:14 +00:00
parent 06151b0ab9
commit 0ba005e7ee
2 changed files with 6 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
internals2/memory/TSRM.xml
View file

@ -4,7 +4,7 @@
<title>Thread-Safe Resource Manager</title>
<simpara>
When PHP is built with Thread Safety enabled, the Zend engine requires a way to isolate contexts from one another, such that the threads of a process may service individual requests without interference. TSRM is omnipitent within PHP, extension authors have to do very little in order to make sure their extensions can function in both a Thread Safe and Non Thread Safe architecture.
When PHP is built with Thread Safety enabled, the engine requires a way to isolate contexts from one another, such that the threads of a process may service individual requests without interference. TSRM is omnipitent within PHP, extension authors have to do very little in order to make sure their extensions can function in both a Thread Safe and Non Thread Safe architecture.
</simpara>
<example xml:id="internals2.structure.globals.using.accessor2">
@ -25,11 +25,11 @@
</simpara>
<simpara>
TSRM manages the isolation and safety of all global structures within PHP, from executor globals to extension globals, a pointer to the isolated storage is also passed around with most, or many of the API functions in the Zend and PHP layers. The macros TSRMLS_C and TSRMLS_CC translate to "thread safe local storage" and "thread safe local storage prefixed with a comma" respectively.
TSRM manages the isolation and safety of all global structures within PHP, from executor globals to extension globals, a pointer to the isolated storage is also passed around with most, or many of the API functions. The macros TSRMLS_C and TSRMLS_CC translate to "thread safe local storage" and "thread safe local storage prefixed with a comma" respectively.
</simpara>
<simpara>
If a function requires a pointer to TSRM, it is declared with the macro TSRMLS_D or TSRMLS_DC in it's prototype, wihch translates to "thread safe local storage only" and "thread safe local storage prefixed with a comma" respectively. Many macros within Zend reference TSRM, so it is a good idea to declare most things to accept TSRM, such that if they need to call upon the Zend API they do not have to fetch a pointer to TSRM during execution, whenever PHP is built in Thread Safe mode TSRM is available by default.
If a function requires a pointer to TSRM, it is declared with the macro TSRMLS_D or TSRMLS_DC in it's prototype, wihch translates to "thread safe local storage only" and "thread safe local storage prefixed with a comma" respectively. Many macros within the engine reference TSRM, so it is a good idea to declare most things to accept TSRM, such that if they need to call upon TSRM they do not have to fetch a pointer during execution, whenever PHP is built in Thread Safe mode TSRM is available by default.
</simpara>
<simpara>

6
internals2/memory/persistence.xml
View file

@ -8,12 +8,12 @@
</simpara>
<simpara>
Persistence can be used, for example, to keep conntections to a database server for multiple requests, Zend provides a sub-api of its emalloc/efree mechanisms, predictably named pemalloc/pefree etc
Persistence can be used, for example, to keep conntections to a database server for multiple requests, the engine provides a sub-api of its emalloc/efree mechanisms, predictably named pemalloc/pefree etc
</simpara>
<note>
<simpara>
All of the following functions take the additional persistent parameter, should this be false, Zend will use its regular allocators (emalloc) and the memory should not be considered persistent. Where memory is allocated as persistent, system allocators are invoked, under most circumstances they are still not able to return NULL pointers just as the Main memory APIs.
All of the following functions take the additional persistent parameter, should this be false, the engine will use its regular allocators (emalloc) and the memory should not be considered persistent. Where memory is allocated as persistent, system allocators are invoked, under most circumstances they are still not able to return NULL pointers just as the Main memory APIs.
</simpara>
</note>
@ -92,7 +92,7 @@
<caution>
<simpara>
It is important to remember that memory allocated to be persistent is not optimized or tracked by the Zend engine; it is not subject to memory_limit.
It is important to remember that memory allocated to be persistent is not optimized or tracked by the engine; it is not subject to memory_limit.
</simpara>
</caution>
</sect1>