> On Dec 21, 2020, at 6:53 PM, Aaron Piotrowski <aa...@trowski.com> wrote: > >> On Dec 21, 2020, at 4:33 PM, Mike Schinkel <m...@newclarity.net >> <mailto:m...@newclarity.net>> wrote: >> >>> On Dec 17, 2020, at 11:30 AM, Aaron Piotrowski <aa...@trowski.com >>> <mailto:aa...@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
