Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112581
Message-ID: <08E75593-0599-48B1-9C2D-D920EE942BAD@trowski.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_2C988518-CFD7-4CDC-964F-204014EE6ACD"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Mon, 21 Dec 2020 17:53:10 -0600
In-Reply-To: <B1FB3E80-0497-48E7-9C70-490CC26CE2B2@newclarity.net>
Cc: php internals <internals@lists.php.net>
To: Mike Schinkel <mike@newclarity.net>
References: <E4BE4688-3CD1-4CE8-A818-5A862F0293F5@trowski.com>
 <B1FB3E80-0497-48E7-9C70-490CC26CE2B2@newclarity.net>
Subject: Re: [PHP-DEV] [RFC] Fibers
From: aaron@trowski.com (Aaron Piotrowski)

--Apple-Mail=_2C988518-CFD7-4CDC-964F-204014EE6ACD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Dec 21, 2020, at 4:33 PM, Mike Schinkel <mike@newclarity.net> =
wrote:
>=20
>> On Dec 17, 2020, at 11:30 AM, Aaron Piotrowski <aaron@trowski.com> =
wrote:
>>=20
>> Hello everyone!
>>=20
>> I would like to introduce an RFC for adding full-stack fibers to PHP: =
https://wiki.php.net/rfc/fibers
>>=20
>> 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.
>>=20
>> An implementation as an extension is at =
https://github.com/amphp/ext-fiber
>>=20
>> 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=E2=80=99m certain many more questions and concerns =
will arise. Looking forward to feedback and discussion.
>>=20
>=20
> This is interesting, and potentially very useful.
>=20
> 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?
>=20
> -Mike
>=20
> 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?"
>=20
> [1] =
https://medium.com/@thejasbabu/concurrency-in-go-e4a61ec96491#:~:text=3DDo=
%20not%20communicate%20by%20sharing,race%20conditions%2C%20memory%20manage=
ment%20etc =
<https://medium.com/@thejasbabu/concurrency-in-go-e4a61ec96491#:~:text=3DD=
o%20not%20communicate%20by%20sharing,race%20conditions%2C%20memory%20manag=
ement%20etc>.

Hi Mike,

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. 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. The RFC does not provide tools to synchronize memory =
access, as these can be implemented in user space. 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.

Cheers,
Aaron Piotrowski


--Apple-Mail=_2C988518-CFD7-4CDC-964F-204014EE6ACD--