Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:112585 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 38098 invoked from network); 22 Dec 2020 02:06:08 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 22 Dec 2020 02:06:08 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 73AED180384 for ; Mon, 21 Dec 2020 17:38:39 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 21 Dec 2020 17:38:38 -0800 (PST) Received: by mail-qt1-f169.google.com with SMTP id y15so8056504qtv.5 for ; Mon, 21 Dec 2020 17:38:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=newclarity-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=huNMMcV/lnKKszz6btGthlJGLZYNwjeRF7oK4KIkCXA=; b=FmB86RuG3k59EGeJ4ykwphk92QaTrFJ24R5375PUqngacCFlZjGR98jYZfW+B1nC7f V/pNDSOR7XuikfGaxHC+X10oRC3FAGUmIwX6816fl7U8YsYeZ+X4mHGGnGI8bgrRqPdC A8AcPYpnYo9UeDFov9LZVoZNV95AmKITei5OY2vcEUtfyUEZi6CREjE+EVXoGaycbcAa w/V7ekTpy5f9OeDQ9VQQxd0Ni9Js8tpFkuQD61EsWCr0BcyAqGIy97Xwe8hXUyzjkswP Lg1LLIjWAiX5Ic/zC5+47b26vta8ZbGEtx3uHdAhcWkRpmcUCDTT61GbQ+xXeLBAy2iV 8hQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=huNMMcV/lnKKszz6btGthlJGLZYNwjeRF7oK4KIkCXA=; b=kNsWkOIrYVBXdBnX7r263sqfpykEK3yrJu4IPFPyNuJx8Hx4Jj/IJ1iv3CiT7sIvdT RfHBfBoEA9e1wqCD4NYrvOKTaIJUITkXys5qFR4IgbNbDSynDkRtWLNFyCMxV4Hr3yjm DzkfilgBoXXVT4WnaFBm/nmJFVvXU3RXiIUngMb6A7ybvGC+NLSUYrS1KxDw5KWgijOk J9C50Y89I2GFB4tCHbkBheB6QSMB5d8SWBhFQ9RP7XL3vgHQ/usvaOp4z83MrL3bUAn4 kDKZytnGW5YGDwtBzY13V4/OrnZh4w4ihIrSnKr7MOg4zW1CqmwVpI7M5pNnStPFK848 cmIQ== X-Gm-Message-State: AOAM53048uJf0SGrQenb927adaFIhzk0ZH+PQVVl6vw+uK+cLAIDvMsB LuhK64o0GX/Ksg0qXuK4lzEvrMkZ7H4bTM/5 X-Google-Smtp-Source: ABdhPJx2aCfr43cO4YWDuK6AKrmip0GLHp/IrbrvfmL5lF37Q3lgvgpIPrwCtGsrBWLI4NCjs4H3DQ== X-Received: by 2002:ac8:45cc:: with SMTP id e12mr19160666qto.59.1608601117832; Mon, 21 Dec 2020 17:38:37 -0800 (PST) Received: from [192.168.1.236] (c-24-98-254-8.hsd1.ga.comcast.net. [24.98.254.8]) by smtp.gmail.com with ESMTPSA id r8sm12114405qtj.94.2020.12.21.17.38.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 Dec 2020 17:38:36 -0800 (PST) Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail=_B288E0F4-4841-4998-BF96-0FEE02B5CDEA" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 21 Dec 2020 20:38:36 -0500 In-Reply-To: <08E75593-0599-48B1-9C2D-D920EE942BAD@trowski.com> Cc: php internals To: Aaron Piotrowski References: <08E75593-0599-48B1-9C2D-D920EE942BAD@trowski.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Subject: Re: [PHP-DEV] [RFC] Fibers From: mike@newclarity.net (Mike Schinkel) --Apple-Mail=_B288E0F4-4841-4998-BF96-0FEE02B5CDEA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 21, 2020, at 6:53 PM, Aaron Piotrowski = wrote: >=20 >> On Dec 21, 2020, at 4:33 PM, Mike Schinkel > wrote: >>=20 >>> On Dec 17, 2020, at 11:30 AM, Aaron Piotrowski > 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 = . >=20 > 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.=20 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.=20 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? =20 > Fibers don't provide the entire API, just the "bare-metal" API needed = to implement various styles of concurrency in user space code. >=20 > AMPHP provides synchronization tools such as mutexes, semaphores, = parcels, and channels in https://github.com/amphp/sync = and 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= --Apple-Mail=_B288E0F4-4841-4998-BF96-0FEE02B5CDEA--