Re: [RFC] Fibers

> On Dec 21, 2020, at 6:53 PM, Aaron Piotrowski <aaron@trowski.com> wrote: > >> On Dec 21, 2020, at 4:33 PM, Mike Schinkel <mike@newclarity.net >> <mailto:mike@newclarity.net>> wrote: >> >>> On Dec 17, 2020, at 11:30 AM, Aaron Piotrowski <aaron@trowski.com >>> <mailto:aaron@trowski.com>> wrote: >>> >>> Hello everyone! >>> >>> I would like to introduce an RFC for adding full-stack fibers to PHP: >>> https://wiki.php.net/rfc/fibers >>> <https://wiki.php.net/rfc/fibers> >>> >>> Fibers are primarily used to implement green-threads or coroutines for asynchronous >>> I/O. Fibers are similar to threads, except fibers exist within a single thread and require >>> cooperative scheduling of the fibers by the process. Since fibers do not require a full CPU context >>> switch, they are lightweight and more performant than multi-processing or threading for awaiting >>> I/O. >>> >>> An implementation as an extension is at >>> https://github.com/amphp/ext-fiber >>> <https://github.com/amphp/ext-fiber> >>> >>> Fibers are a complex feature. The RFC contains many examples and links to code using >>> fibers to help explain and demonstrate what is possible, however I’m certain many more questions >>> and concerns will arise. Looking forward to feedback and discussion. >>> >> >> This is interesting, and potentially very useful. >> >> I am curious about how you propose access to shared memory across fibers? What will happen >> if two fibers try to update a $GLOBALS variable at the same time? Or a property of the same object? >> How will developers manage that? >> >> -Mike >> >> P.S. Have you considered concurrency functionality like in GoLang[1] e.g. channels, where >> the mantra is "Do not communicate by sharing memory; instead, share memory by >> communicating?" >> >> [1] >> https://medium.com/@thejasbabu/concurrency-in-go-e4a61ec96491#:~:text=Do%20not%20communicate%20by%20sharing,race%20conditions%2C%20memory%20management%20etc >> <https://medium.com/@thejasbabu/concurrency-in-go-e4a61ec96491#:~:text=Do >> not communicate by sharing,race conditions, memory management etc>. > > Hi Mike, Thanks for the reply. > Fibers do not change the single-threaded nature of PHP. Only a single fiber can be running at > one time, so memory cannot be modified simultaneously. There are synchronization issues when writing > asynchronous code using either stackless or stackful coroutines, as anyone who has worked with AMPHP > or ReactPHP can tell you. Multiple fibers (coroutines, green-threads, whatever you want to call > them) will interleave execution. So if I am to understand correctly, one fiber could block all others, so fiber code will need to be well-behaved and not block much like how Node code must not block when used as a web server? If I understand correctly, no need to reply about this. > Multiple interleaved fibers can change object state between pausing and resuming, which > I'm guessing is more to what you were concerned about, rather than literal simultaneous > modification that can occur with threads. Correct. > The RFC does not provide tools to synchronize memory access, as these can be implemented in > user space. Would it be appropriate of me to ask for a section that discusses how that might be done in user space in the RFC, at least with some simple pseudo-code, or if is it non-trivial than a link to where it is discussed in depth? > Fibers don't provide the entire API, just the "bare-metal" API needed to > implement various styles of concurrency in user space code. > > AMPHP provides synchronization tools such as mutexes, semaphores, parcels, and channels in > https://github.com/amphp/sync > <https://github.com/amphp/sync> and > https://github.com/amphp/parallel > <https://github.com/amphp/parallel>. Other libraries could > provide similar tools, though perhaps with a different approach. We too like the Go-style of > concurrency and look to emulate it in AMPHP v3. Thanks in advance. -Mike