rfc:php_native_interface

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
rfc:php_native_interface [2009/04/05 18:58] – linkify pbiggarrfc:php_native_interface [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 6: Line 6:
  
  
-Design of the design of *phpni*, a native interface for PHP, designed to replace the Zend API.+Design of the design of //phpni//, a native interface for PHP, designed to replace the Zend API.
  
-See also [[remove_zend_api]]. +The need for such a native interface is described separately in [[remove_zend_api]].
- +
- +
-===== Why do we need a PHP Native Interface? ===== +
- +
-The rationale is explained separately in [[remove_zend_api]].+
  
  
 ===== 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.+This describes the design of //phpni//, the PHP Native Interface. This design is in early stages.
  
  
Line 28: Line 23:
     * proving access to C libraries     * proving access to C libraries
     * providing the ability to rewrite performance sensitive code in C     * providing the ability to rewrite performance sensitive code in C
 +  * Significantly simplify creation of extensions
 +  * Allow other PHP implementations to use the same interface.
 +  * This is intended to be a **static** process. That is, we are replacing the static compilation of extensions with another static process. We do not intend to simplify or support run-time binding, like //JNI//, //JNA// or //libffi//. Instead it is imagined the result will be a single libphplibs.a, which statically links into libphp5.so.
  
  
Line 69: Line 67:
 </file> </file>
  
-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.+=== Interface === 
 +In order to interface between the PHP code and the C functions, a tool will be required to generate code. This tool will obviously be implementation specific. SWIG could be used to create this.
  
 === Zend engine === === Zend engine ===
Line 81: Line 80:
 === Embed SAPI === === 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.+The same interface used for libraries can be used to handle many of the use cases of the C API. However, we do need to specify a means to call PHP user code from C/C++ code.
  
  
Line 88: Line 87:
 Since PHP extensions are no longer written in the Zend API, other PHP implementations, such as Roadsend, Project Zero, Phalanger and Quercus should be reuse the libraries without difficulty. In addition, if the coupling is between the interpreter and its components is simple enough, it may be possible for other implementations to be slotted in directly. However, though this would be a nice side-effect, it should probably not be considered a priority. Since PHP extensions are no longer written in the Zend API, other PHP implementations, such as Roadsend, Project Zero, Phalanger and Quercus should be reuse the libraries without difficulty. In addition, if the coupling is between the interpreter and its components is simple enough, it may be possible for other implementations to be slotted in directly. However, though this would be a nice side-effect, it should probably not be considered a priority.
  
 +Note that the design described requires the Zend engine to generate interfacing code from the phpni specification. Other implementations would be required to generate their own code for this interface.
 +
 +Input from other PHP implementations:
 +
 +  * Project Zero
 +    * Supportive (see [[http://wiki.php.net/rfc/remove_zend_api/scratchpad|remove_zend_api/scratchpad]] for their discussion.
 +  * phc
 +    * Involved
 +  * Roadsend
 +    * TODO
 +  * Phalanger
 +    * TODO
 +  * Quercus
 +    * TODO
 +    
 +
 +===== 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:
 +    * Who will be responsible for freeing passed memory?
 +
 +  * Arrays
 +    * It is likely that each implementation will have to implement their own array extension (the term "extension" is probably misleading for something so fundamental to the language).
 +
 +=== 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.
 +  * strings:
 +    * representing length
 +      * The php_string structure created on the C side should have a length
 +    * mutability
 +      * The php_string structure created on the C side should either be of type mutable_string/immutable_string, or have a mutable flag.
 +      * Does the implementation have to respect this too? Probably.
 +    * Unicode
 +      * This should come for free?
  
 ===== Similar projects ===== ===== Similar projects =====
Line 93: Line 132:
 === 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://docs.python.org/library/ctypes.html   * ctypes (Python) http://docs.python.org/library/ctypes.html
Line 104: Line 143:
   * Haskell 98 Foreign Function Interface http://www.cse.unsw.edu.au/~chak/haskell/ffi/   * Haskell 98 Foreign Function Interface http://www.cse.unsw.edu.au/~chak/haskell/ffi/
   * CFFI (Common Lisp): Common-Lisp FFI: http://common-lisp.net/project/cffi/   * CFFI (Common Lisp): Common-Lisp FFI: http://common-lisp.net/project/cffi/
 +  * SICStus Prolog FLI: http://www.sics.se/sicstus/docs/latest/html/sicstus.html/Mixing-C-and-Prolog.html
  
 === For PHP === === For PHP ===
Line 110: Line 150:
  
   * FFI http://pecl.php.net/package/ffi   * FFI http://pecl.php.net/package/ffi
 +    * This is an interface to libffi, and is therefore not suitable directly.
 +    * Some ideas may still be suitable
   * CodeGen_PECL http://pear.php.net/package/CodeGen_PECL/   * CodeGen_PECL http://pear.php.net/package/CodeGen_PECL/
   * Inline_C http://pear.php.net/package/Inline_C   * Inline_C http://pear.php.net/package/Inline_C
Line 117: Line 159:
  
 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: 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:
 +
 +  * Discuss requirements with other PHP implementations
  
   * Prototype a single library   * Prototype a single library
     * perhaps readline?     * perhaps readline?
-    * Manually write interface code between the header and the PHP code.+    * Manually write interface code between phpni code and the PHP code. 
 +    * Look at other implementations, in particular JNI
  
-  * Discuss requirements with other PHP implementations + 
-   +  * Write a utility to generate the interface code automatically for the Zend engine
-  * Write a utility to generate the interface code automatically+
     * Using SWIG?     * Using SWIG?
     * Test 5 or 6 libraries     * Test 5 or 6 libraries
     * Test more complicated functionality     * Test more complicated functionality
 +  * Work with other implementations to prototype the same
  
   * 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. +  * At some point we'll need to get consensus from PHP-internals developers that this is a good idea, and a commitment to use it.
- +
  
rfc/php_native_interface.1238957920.txt.gz · Last modified: 2017/09/22 13:28 (external edit)

Page Tools