rfc:php_native_interface
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revisionNext revisionBoth sides next revision | ||
rfc:php_native_interface [2009/04/05 16:32] – created by direct copy of remove_zend_api. pbiggar | rfc:php_native_interface [2009/04/09 11:15] – Remove duplicate text pbiggar | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== | + | ====== |
* Version: 1.0.x | * Version: 1.0.x | ||
* Date: 2009-03-27 | * Date: 2009-03-27 | ||
Line 6: | Line 6: | ||
- | Provides a rationale for replacing | + | Design of the design of //phpni//, a native interface for PHP, designed |
- | ===== Introduction ===== | + | The need for such a native interface is described separately |
- | + | ||
- | This RFC is in two parts, which will probably be split off in the future: | + | |
- | + | ||
- | * The need to remove external access to the Zend Engine (aka remove the Zend API) | + | |
- | * The design of a " | + | |
- | + | ||
- | + | ||
- | + | ||
- | ===== Why remove the Zend API? ===== | + | |
- | + | ||
- | === Zend API === | + | |
- | + | ||
- | 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 | + | |
- | + | ||
- | * Used to write PHP's standard libraries, 3rd party extensions, and much of PECL. | + | |
- | * Allows wrapping of C/C++ libraries in order to allow the to be accessed from user-code. | + | |
- | * Allows hot (performance-sensitive) code to be rewritten in C for speed | + | |
- | * Used to embed PHP into within C/C++ applications using the embed SAPI | + | |
- | + | ||
- | === 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 Zend Engine and its clients, restricting greatly our ability to change the Zend Engine. By requiring backwards compatability with the Zend Engine, we are ensuring that the Zend Engine can only be modified in minor ways. This holds the Zend Engine to design decisions made nearly 10 years ago, and prevents PHP from getting much faster in the long term. | + | |
- | + | ||
- | 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. They have chosen different strategies: | + | |
- | + | ||
- | * 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. | + | |
- | + | ||
- | + | ||
- | The second half of this RFC describes a solution to this issue: the PHP Native Interface. 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, | + | |
===== phpni: The PHP Native Interface ===== | ===== phpni: The PHP Native Interface ===== | ||
- | This describes the design of *phpni*, the PHP Native Interface. This design is in early stages. The stages required until completion are described later (link?). | + | This describes the design of //phpni//, the PHP Native Interface. This design is in early stages. The stages required until completion are described later. |
Line 97: | Line 64: | ||
</ | </ | ||
- | In order to interface between | + | === Interface === |
+ | In order to interface between | ||
=== Zend engine === | === Zend engine === | ||
Line 116: | Line 84: | ||
Since PHP extensions are no longer written in the Zend API, other PHP implementations, | Since PHP extensions are no longer written in the Zend API, other PHP implementations, | ||
+ | ===== Problems with current design ===== | ||
+ | |||
+ | As the design progresses, problems will be identified, which must be solved. This section will keep track of them: | ||
+ | |||
+ | === Problems to be dealt with === | ||
+ | |||
+ | * Strings: | ||
+ | * How can we identify that an int field is the length of char* field? | ||
+ | * Who will be responsible for freeing passed memory? | ||
+ | * How do we decide whether to make a copy of the string? | ||
+ | * How do we know if we can modify the string in place? | ||
+ | * TODO: look at how JNI does it | ||
+ | |||
+ | === Problems solved === | ||
+ | |||
+ | * Performance of say, pointer arithmetic, will suffer | ||
+ | * With the basic design (v1.0), it should be simple to put a C layer above the C library, and wrap that instead. | ||
===== Similar projects ===== | ===== Similar projects ===== | ||
Line 121: | Line 106: | ||
=== Non-PHP === | === Non-PHP === | ||
- | phpni differs from many of these in that it is designed not to add new features, but instead to replace an existing facility - the ability to call C libraries. As such, dynamic linking is not part of the spec. | + | //phpni// differs from many of these in that it is designed not to add new features, but instead to replace an existing facility - the ability to call C libraries. As such, dynamic linking is not part of the spec. |
* ctypes (Python) http:// | * ctypes (Python) http:// | ||
Line 132: | Line 117: | ||
* Haskell 98 Foreign Function Interface http:// | * Haskell 98 Foreign Function Interface http:// | ||
* CFFI (Common Lisp): Common-Lisp FFI: http:// | * CFFI (Common Lisp): Common-Lisp FFI: http:// | ||
+ | * SICStus Prolog FLI: http:// | ||
=== For PHP === | === For PHP === | ||
Line 149: | Line 135: | ||
* perhaps readline? | * perhaps readline? | ||
* Manually write interface code between the header and the PHP code. | * Manually write interface code between the header and the PHP code. | ||
+ | * Solve problems raised in email discussion | ||
+ | * Look at other implementations, | ||
* Discuss requirements with other PHP implementations | * Discuss requirements with other PHP implementations | ||
Line 158: | Line 146: | ||
* Convert entire set of PHP extensions | * Convert entire set of PHP extensions | ||
- | |||
- | |||
- | Naturally, before the last step it will be necessary to get consensus from other internals developers that this is a good idea. It would be worthwhile to produce a document discussing the experience so far. | ||
rfc/php_native_interface.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1