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
Next revisionBoth sides next revision
rfc:fiber [2018/04/17 23:52] lvhtrfc:fiber [2018/06/10 12:07] lvht
Line 3: Line 3:
   * Date: 2017-09-13   * Date: 2017-09-13
   * Author: Haitao Lv<i@lvht.net>, Dmitry Stogov<dmitry@zend.com>, Martin Schröder<m.schroeder2007@googlemail.com>   * Author: Haitao Lv<i@lvht.net>, Dmitry Stogov<dmitry@zend.com>, Martin Schröder<m.schroeder2007@googlemail.com>
-  * Status: Under Discussion+  * Status: Voting
   * First Published at: http://wiki.php.net/rfc/fiber   * First Published at: http://wiki.php.net/rfc/fiber
  
Line 81: Line 81:
  
 === Implementation Detail === === Implementation Detail ===
-In our simple implementation, we only backup/restore the **zend stack**. If you pause a Fiber in some internal function call like `array_map`, the c stack frame maybe over write which will trigger coredump. +In our simple implementation, we only backup/restore the **zend stack**. We **cannot** pause a Fiber during internal function call like `array_map`.
- +
-Martin Schröder has another implementation at https://github.com/fiberphp/fiber-ext/pull/30. Martin's work backup/restore both the zend stack and the c stack. +
- +
- +
-^Property^Martin's Fiber^Our Fiber^ +
-|Minimum Memory Usage|VM stack only (4 KB)|VM & C stack (4 KB + 4 KB)| +
-|Supported Architecturs|any platform supported by compiler|only x86 systems at this time| +
-|Yield in Internal Function|unsupported|supported| +
-|Yield in Iterator|unsupported|supported|+
  
 ===== Backward Incompatible Changes ===== ===== Backward Incompatible Changes =====
Line 116: Line 107:
  
 ===== Open Issues ===== ===== Open Issues =====
-<blockquote>What happens if there are internal calls on the call stack?Say something like array_map(function() { await; }, [1, 2, 3]); inside a fiber.  +<blockquote>Why not support backup/restore the stack?</blockquote> 
-</blockquote>+Martin Schröder is working on this at https://github.com/fiberphp/fiber-ext/pull/30. 
  
-Calling Fiber::yield in a internal call will trigger a fatal error.+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|
  
-<blockquote>How do you determine when a fiber has returned? Separate methods similar to Generator would be better.</blockquote>+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).
  
-Offering methods like **Fiber::alive()**,**Fiber::running()** makes any meaningful difference to check the return value of Fiber::status(). It is just a coding style issue.+Native fibers are very platform-dependend (2and 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.
  
-And as a language feature, Fiber should only offer the essential API and let other works to the userland code.+<blockquote>Why not introduce helper like **Fiber::alive(),Fiber::running()**?</blockquote>
  
-<blockquote>Using Fiber::resume() to initialize the fiber and resume feels awkward. Separate methods again would be better.</blockquote>+And as a language feature, Fiber should only offer the essential API. User can implement these methods in user land code easily. 
 + 
 +<blockquote>Why not introduce a dedicate method other than **Fiber::resume()** for Fiber initialization?</blockquote>
  
 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>I think a keyword here would be beneficial, even if it has a minor BC impact.</blockquote> 
- 
-Introducing new keywords does not offer any essential benefit but only cause BC impact. 
- 
-Both Ruby's Fiber and Lua's coroutine use method to pause and resume their coroutine. 
  
 ===== Unaffected PHP Functionality ===== ===== Unaffected PHP Functionality =====
Line 141: 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.+ 
 +Syntax like async/await can be implemented in the future, but it's out of the scope of this RFC.
  
 ===== Proposed Voting Choices ===== ===== Proposed Voting Choices =====
rfc/fiber.txt · Last modified: 2018/06/12 07:40 by krakjoe