rfc:remove_zend_api
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
rfc:remove_zend_api [2009/03/30 22:42] – Flesh out the project plan, and finish solution discussion pbiggar | rfc:remove_zend_api [2009/04/08 19:00] – pbiggar | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== | + | ====== |
- | * Version: 1.0 | + | * Version: 1.1 |
* Date: 2009-03-27 | * Date: 2009-03-27 | ||
* Author: Paul Biggar < | * Author: Paul Biggar < | ||
- | * Status: | + | * Status: |
+ | ===== Introduction ===== | ||
- | A better way to provide a C API, with particular emphasis on decoupling extensions from the interpreter. | + | Currently, PHP's interpreter, |
- | ===== Introduction ===== | + | This RFC does not describe how to remove access, and what to replace it with. That is described separately, in [[php_native_interface]]. The goals of this RFC are predicated on achieving the goals of [[php_native_interface]]. |
- | ** Naturally, this seems insane. Please bear with me. ** | ||
- | ===== What' | + | ===== Why remove |
=== Zend API === | === Zend API === | ||
Line 19: | Line 19: | ||
The Zend API is a large set of functions, macros and data-structures which are used to interact with the Zend Engine. It serves 3 major purposes, roughly in order of importance: | The Zend API is a large set of functions, macros and data-structures which are used to interact with the Zend Engine. It serves 3 major purposes, roughly in order of importance: | ||
- | * Used to write PHP's standard libraries, 3rd party extensions, and much of PECL | + | * Used to write PHP's standard libraries, 3rd party extensions, and much of PECL. |
- | * Allows hot (performance-sensitive) code to be rewritten in C for speed | + | * Allows wrapping of C/C++ libraries in order to allow the to be accessed from user-code. |
+ | | ||
* Used to embed PHP into within C/C++ applications using the embed SAPI | * Used to embed PHP into within C/C++ applications using the embed SAPI | ||
=== Problems === | === Problems === | ||
- | The main problem with it is that it constrains the implementation of the Zend Engine. The Zend API creates a tight coupling between the ZendEngine | + | The main problem with it is that it constrains the implementation of the Zend Engine. The Zend API creates a tight coupling between the Zend Engine |
- | + | ||
- | The Zend API also makes it difficult to write PHP extensions. Although most of the API is not terribly difficult to work with, concepts like copy-on-write, | + | |
- | + | ||
- | A number of other PHP implementations exist, such as IBM's Project Zero, Phalanger, Roadsend, Quercus and phc. Many of these projects find it very difficult to re-use PHP's standard libraries. Quercus and Roadsend have reimplemented popular standard libraries. Phalanger and Project Zero attempt to re-use the existing libraries by marshalling their data into the Zend API. This appears to be slow and error-prone. phc is designed around reusing the Zend API for compatibility with the PHP. This constrains many of the optimizations phc would wish to perform, since it uses the Zend API nearly everywhere. | + | |
- | + | ||
- | + | ||
- | ===== What's the solution? ===== | + | |
- | + | ||
- | === Design Criteria === | + | |
- | + | ||
- | * Greatly reduce the coupling between the Zend Engine and its users | + | |
- | * Support all major use cases of the Zend API | + | |
- | * preferably simplifying each use case | + | |
- | + | ||
- | + | ||
- | === Solution === | + | |
- | + | ||
- | Take the use case of wrapping a C library to expose its functionality in user space. The major idea is to " | + | |
- | + | ||
- | Lets take a simple example. Assume we have a C library XXX, with 3 functions, x, y and z. We'd like to expose this in user space as a class called MyXXX, with methods a and b. We create a file with the signatures of x, y and z: | + | |
- | + | ||
- | extensions/ | + | |
- | < | + | |
- | int x (int, int); | + | |
- | void y (char*, int); | + | |
- | void z (char*, int); | + | |
- | </ | + | |
- | + | ||
- | We then write our user space code: | + | |
- | + | ||
- | extensions/ | + | |
- | < | + | |
- | class MyXXX | + | |
- | { | + | |
- | | + | |
- | { | + | |
- | | + | |
- | } | + | |
- | + | ||
- | | + | |
- | { | + | |
- | $foo = \internals\XXX\x ($w1, $w2); | + | |
- | \internals\XXX\y ($this-> | + | |
- | } | + | |
- | + | ||
- | | + | |
- | { | + | |
- | $foo = \internals\XXX\x ($m1, $m2); | + | |
- | \internals\XXX\z ($this-> | + | |
- | return $foo; | + | |
- | } | + | |
- | } | + | |
- | </ | + | |
- | + | ||
- | In order to interface between these two, it will be necessary to have a tool to automatically wrap the C functions. SWIG could be used to create this tool. | + | |
- | + | ||
- | === Zend engine === | + | |
- | + | ||
- | Since the libraries would no longer use the Zend API, the tight coupling would be broken. It would now be possible to change major parts of the Zend engine without affecting the operation of any other part of PHP. | + | |
- | + | ||
- | === Extensions/ | + | |
- | + | ||
- | It would no longer be necessary to know the Zend API to write extensions. Instead, only the API of the C library is necessary, and the interface can be created in PHP user code. | + | |
- | + | ||
- | === Embed SAPI === | + | |
- | + | ||
- | The same interface used for libraries can be used to handle many of the use cases of the C API. However, it is likely that a means to call PHP user code from C/C++ code, will be required. | + | |
- | + | ||
- | + | ||
- | === Other PHP implementations === | + | |
- | Since PHP extensions | + | The Zend API also makes it difficult to write PHP extensions. Although most of the API is not terribly difficult to work with, concepts like copy-on-write, change-on-write sets, and separation appear to be tricky concepts for many people. The only documentation is Sara Golemon' |
+ | A number of other PHP implementations exist, such as IBM's Project Zero, Phalanger, Roadsend, Quercus and phc. Many of these projects find it very difficult to re-use PHP's standard libraries. They have chosen different strategies: | ||
- | ===== Project | + | * Quercus and Roadsend have reimplemented popular extensions. This means that probably 90% of extensions are unavailable. It also means that future and private extensions cannot be available. |
+ | * Phalanger and Project | ||
+ | * phc is designed around reusing the Zend API for compatibility with the PHP. This constrains many of the optimizations phc would wish to perform. | ||
- | This is a simple design. In reality, it would need to be prototyped to determine whether this makes sense for every use case, and that there would be little sacrificed to make it work. The work on it should probably progress in roughly the following order: | ||
- | * Prototype a single library | ||
- | * perhaps readline? | ||
- | * Manually write interface code between the header and the PHP code. | ||
- | * Discuss requirements with other PHP implementations | ||
- | | ||
- | * Write a utility to generate the interface code automatically | ||
- | * Using SWIG? | ||
- | * Test 5 or 6 libraries | ||
- | * Test more complicated functionality | ||
- | * Convert entire set of PHP extensions | + | ===== How to proceed ====== |
- | Naturally, before | + | A proposed replacement for the Zend API is described in [[php_native_interface]]. However, |
+ | This RFC is a means of achieving concensus on removing the Zend API in PHP 6, predicated on first achieving the goals in [[php_native_interface]]. | ||
rfc/remove_zend_api.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1