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/29 14:37] – typo fix pbiggar | rfc:remove_zend_api [2009/04/05 19:33] – linkify pbiggar | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== | + | ====== |
* Version: 1.0 | * Version: 1.0 | ||
* Date: 2009-03-27 | * Date: 2009-03-27 | ||
* Author: Paul Biggar < | * Author: Paul Biggar < | ||
- | * Status: | + | * Status: |
+ | ===== Introduction ===== | ||
- | A better way to provide | + | This RFC provides |
- | ===== Introduction ===== | + | See also 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, | + | 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. | + | 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 extensions. This means that probably 90% of extensions are unavailable. It also means that future and private extensions cannot be available. | ||
+ | * 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. In particular, Project Zero reports speed problems from marshalling Unicode strings into the Zend API (and those are then passed to C libraries, possably requiring extra marshaling). | ||
+ | * phc is designed around reusing the Zend API for compatibility with the PHP. This constrains many of the optimizations phc would wish to perform. | ||
- | ===== What's the solution? ===== | ||
- | === Design Criteria === | + | A proposed replacement for the Zend API is described in php_native_interace. However, to actually solve this issue, a decision must be made to not only use the PHP Native Interface to provide an interface between extensions and implementations, |
- | * 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: | ||
- | |||
- | xxx/sigs.h | ||
- | < | ||
- | int x (int, int); | ||
- | void y (char*, int); | ||
- | void z (char*, int); | ||
- | </ | ||
- | |||
- | We then write our user space code: | ||
- | |||
- | xxx/ | ||
- | < | ||
- | class MyXXX | ||
- | { | ||
- | | ||
- | { | ||
- | | ||
- | } | ||
- | |||
- | | ||
- | { | ||
- | $foo = \internals\XXX\x ($w1, $w2); | ||
- | \internals\XXX\y ($this-> | ||
- | } | ||
- | |||
- | | ||
- | { | ||
- | $foo = \internals\XXX\x ($m1, $m2); | ||
- | \internals\XXX\z ($this-> | ||
- | return $foo; | ||
- | } | ||
- | } | ||
- | </ | ||
Line 84: | Line 44: | ||
===== Project Plan ===== | ===== Project Plan ===== | ||
- | This is a simple design. In reality, it would need to be prototyped to determine | + | This is a simple design. In reality, it would need to be prototyped to determine |
- | + | ||
- | + | ||
- | ==== Links ==== | + | |
+ | * Follow the Project Plan in [[php_native_interface]] | ||
+ | * Convert all PHP extensions | ||
- | ===== Changelog ===== | + | Naturally, before the last step it will be necessary to get consensus from other internals developers that this is a good idea. |
rfc/remove_zend_api.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1