rfc:fiber

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:fiber [2018/04/18 22:36] – lvhtrfc:fiber [2018/06/12 07:40] (current) – move back to discussion krakjoe
Line 82: Line 82:
 === Implementation Detail === === Implementation Detail ===
 In our simple implementation, we only backup/restore the **zend stack**. We **cannot** pause a Fiber during internal function call like `array_map`. In our simple implementation, we only backup/restore the **zend stack**. We **cannot** pause a Fiber during internal function call like `array_map`.
- 
-Backup/restore both the zend stack and the the c statck is impossible. However, it is platform dependent and more  complicated. 
- 
-Martin Schröder is working on this at https://github.com/fiberphp/fiber-ext/pull/30. 
- 
-^Property^Full stack Fiber^Zend stack Fiber^ 
-|Code Base|c & asm|c| 
-|Minimum Memory Usage|VM stack only (4 KB)|VM & C stack (4 KB + 4 KB)| 
-|Supported Architecturs|any platform|x86 at this time| 
-|Yield in Internal Function|unsupported|supported| 
  
 ===== Backward Incompatible Changes ===== ===== Backward Incompatible Changes =====
Line 117: Line 107:
  
 ===== Open Issues ===== ===== Open Issues =====
 +<blockquote>Why not support backup/restore the c stack?</blockquote>
 +Martin Schröder is working on this at https://github.com/fiberphp/fiber-ext/pull/30. 
 +
 +And here is the comparison.
 +^Property^Stackless Fiber^Native Fiber^
 +|1 Minimum Memory Usage|VM stack only (4 KB)|VM & C stack (4 KB + 4 KB)|
 +|2 Supported Architecturs|any platform|x86 at this time|
 +|3 Yield in Internal Function|unsupported|supported|
 +|4 Yield in Iterator|unsupported|supported|
 +
 +Stackless fiber use less memory and are not platform-dependend (1 & 2) which makes them very portable and efficient. They do however lack support for anything that involves internal function calls (3) including opcode handlers (4, e.g. foreach loop).
 +
 +Native fibers are very platform-dependend (2) and use more memory because they do need to allocate a C call stack (1). While memory allocation will be done using mmap() it will still reserve virtual memory (can be problematic for a large number of fibers on 32 bit systems due to limited virtual memory addressing). The big advantage is that all kinds of internal function call (3 & 4) are supported without any changes to the existing codebase.
 +
 <blockquote>Why not introduce helper like **Fiber::alive(),Fiber::running()**?</blockquote> <blockquote>Why not introduce helper like **Fiber::alive(),Fiber::running()**?</blockquote>
  
Line 124: Line 128:
  
 Both Ruby's Fiber and Lua's coroutine using the same **resume()** API to **init** and **resume** their coroutine. Both Ruby's Fiber and Lua's coroutine using the same **resume()** API to **init** and **resume** their coroutine.
- 
-<blockquote>Why not introduce keyword like async/await?</blockquote> 
- 
-Introducing new keywords will cause BC impact. Both Ruby's Fiber and Lua's coroutine does not have such keyword as well. 
  
 ===== Unaffected PHP Functionality ===== ===== Unaffected PHP Functionality =====
Line 133: Line 133:
  
 ===== Future Scope ===== ===== Future Scope =====
-This sections details areas where the feature might be improved in future, but that are not currently proposed in this RFC. 
  
-===== Proposed Voting Choices ===== +Syntax like async/await can be implemented in the future, but it's out of the scope of this RFC.
-2/3+1 voting majority+
  
 ===== Patches and Tests ===== ===== Patches and Tests =====
rfc/fiber.1524090993.txt.gz · Last modified: 2018/04/18 22:36 by lvht

Page Tools