mirror of
https://github.com/php/pecl-search_engine-solr.git
synced 2026-03-23 22:52:07 +01:00
1e427e55f2
This patch adds some missing newlines and trims redundant final newlines into a single one. According to POSIX, a line is a sequence of zero or more non-' <newline>' characters plus a terminating '<newline>' character. [1] Files should normally have at least one final newline character. C89 [2] and later standards [3] mention a final newline: "A source file that is not empty shall end in a new-line character, which shall not be immediately preceded by a backslash character." Although it is not mandatory for all files to have a final newline fixed, a more consistent and homogeneous approach brings less of commit differences issues and a better development experience in certain text editors and IDEs. [1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206 [2] https://port70.net/~nsz/c/c89/c89-draft.html#2.1.1.2 [3] https://port70.net/~nsz/c/c99/n1256.html#5.1.1.2
55 lines
2.7 KiB
Plaintext
55 lines
2.7 KiB
Plaintext
================================================================================
|
|
Solr Notes about Memory Allocation and interaction with HashTables
|
|
================================================================================
|
|
|
|
The following notes are for C-space PHP developers.
|
|
|
|
If you are not really familiar with how the Zend HashTable API or the
|
|
memory allocation marcros really works, please take sometime to read the notes below :
|
|
|
|
This is correct as of Zend Engine version 2.3.0
|
|
|
|
- If memory was allocated with emalloc(), it has to be freed with efree().
|
|
|
|
- If memory was allocated using pemalloc(), the same value for the persistent
|
|
parameter must be used during pefree() to deallocated the allocated memory.
|
|
The memory manager for the Zend API will then decide whether to use free() or
|
|
efree() depending on whether persistent is 1 or 0 respectively. The same
|
|
principle applies to pestrdup(), pecalloc() and the other memory allocation
|
|
macros.
|
|
|
|
- When inserting values into the HashTables, if the value for the persistent
|
|
parameter is set, then the memory allocation for the entered item should be
|
|
persistent to i.e. pemalloc() with persistent set to 1.
|
|
|
|
The following will apply when adding new values into a HashTable for items
|
|
that were dynamically allocated :
|
|
|
|
(a) If the value for the nDataSize parameter is the size of that of a
|
|
pointer sizeof(void *), the HashTable API copies the contents of
|
|
the pData parameter into the Bucket->pDataPtr member for that data Bucket.
|
|
Then it sets the Bucket->pData member to the address of the Bucket->pDataPtr
|
|
member for that data Bucket.
|
|
|
|
(b) If the value for the nDataSize parameter is not equal to sizeof(void *),
|
|
the HashTable API allocates new memory for the Bucket->pData member using
|
|
the size equivalent to nDataSize and the same value for the persistent flag
|
|
set for the target HashTable. The the contents of the pData parameter is
|
|
copied into the Bucket->pData member in this newly allocated memory location.
|
|
Then the Bucket->pDataPtr member for this Bucket is set to NULL.
|
|
|
|
Do not worry about the newly allocated memory allocated by the HashTable API;
|
|
if the nDataSize parameter was not equal to sizeof(void *), then
|
|
during the cleanup process, the Zend API will free the new memory it allocated
|
|
during the insert process.
|
|
|
|
It will also call the destructor function if a valid one was passed when the
|
|
HashTable was initialized with zend_hash_init().
|
|
|
|
In the extension, I have used the p* version of the memory allocation functions
|
|
to allow me toggle if there is any need to do so in the future. This will prevent
|
|
a massive search and replace effort.
|
|
|
|
For all the HashTables, I set the intial size to 8 to reduce the looping when
|
|
zend_hash_init() is setting up the HashTable pointer to use.
|