Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113050 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 8724 invoked from network); 2 Feb 2021 15:11:22 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 2 Feb 2021 15:11:22 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id DC70D1804DD for ; Tue, 2 Feb 2021 06:54:36 -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=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com [209.85.208.174]) (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 ; Tue, 2 Feb 2021 06:54:36 -0800 (PST) Received: by mail-lj1-f174.google.com with SMTP id m22so16852041ljj.4 for ; Tue, 02 Feb 2021 06:54:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ALoHrt6J0Au9HPGI3ePgKdNgHNGIliHAkoYTZ2Df+3o=; b=LNJQVyOeU8fKK/6JaWA0Xb3mT2fEeahE9hi9qhoMqX+YqO1MdIRlwlRyYVQqg6I32b 7pP3vddgt04XOa/knmBe1QmbMl4aCLcapmYbMXn7PsXultEwFKbXME46m+9S1C+oZMNo y9F1cFS5D2i0iiDX1TtBrMM74DBR65OqxC6EucbmfkFBiprzngcD3Am6G6rxu3Z8jZV4 Piumop24KdGiEEnUDJIZdI92bzmKiSzXP9TRCy5YxvkHVw/Je86d5ZKXjvcmeVtQo2zV oXjqwzfU8xrgUu90ik7XLrKv3B9AoM9WkCm+HB+hj136kCSTWq06OImnrvoF2uMN4h42 ljRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ALoHrt6J0Au9HPGI3ePgKdNgHNGIliHAkoYTZ2Df+3o=; b=cEGsxDum/j0ilITfA5FU/zRKOsGpLJU4r2Ph5OZYNOpSBYFfB59ceSV5/TF4CAtowg hyi3JcwS2ggrNKItJ7yL/GNc/7317bNw9T2uXtWooXtiHNLjwEQE64+XPkquI5nXjLpV SGw7XcBcaB+ddWpOGS9yty/nNPoVFdqr1wN4lnrtyXlt/zlJ88bwSRi5aKOp5QqLwTer c11Y4kHafJNtVljJMlZaEN2ow9eDWjVAkb+s7+TFAL0QF16wto9RKmSltFMoGVq2OH24 DuW/aZG/Jh92esXq/oWBg1DgEnBfhcFJIqLWdIawAHgSUn11dCtY5Y93E5Fpi1RKg4Oe z9rg== X-Gm-Message-State: AOAM531bCuO6LygiZt3ZDztnHpm3TXEm875yPALny3srPVJEVIPki+k2 7ODtaLLLwCLy/SsRCxUOPfQDgdXNEhM3tO4c3KgEWb2ukXk= X-Google-Smtp-Source: ABdhPJz0kiB6V4TGJsTTpIT5n1eLKR0yC/ElWUE2+Xhmtc/F+khwmUo/IzPkg2dG9TBSXPq8JcvGvXr5esjKm47VRBo= X-Received: by 2002:a2e:9d96:: with SMTP id c22mr13495739ljj.109.1612277672215; Tue, 02 Feb 2021 06:54:32 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 2 Feb 2021 15:54:16 +0100 Message-ID: To: Aaron Piotrowski Cc: php internals Content-Type: multipart/alternative; boundary="000000000000ee8af905ba5ba55d" Subject: Re: [PHP-DEV] [RFC] Fibers From: nikita.ppv@gmail.com (Nikita Popov) --000000000000ee8af905ba5ba55d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Dec 17, 2020 at 5:30 PM Aaron Piotrowski wrote: > Hello everyone! > > I would like to introduce an RFC for adding full-stack fibers to PHP: > 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 with= in > 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-fibe= r > > Fibers are a complex feature. The RFC contains many examples and links to > code using fibers to help explain and demonstrate what is possible, howev= er > I=E2=80=99m certain many more questions and concerns will arise. Looking = forward to > feedback and discussion. > Hi Aaron, Thank you for the proposal. Ergonomics of async I/O in PHP certainly leave something to be desired right now, and improvements in this area are welcome. Despite your explanations in the RFC and this thread, I'm still having a hard time understanding the purpose of the FiberScheduler. My current understanding is that the FiberScheduler is a special type of fiber that cannot be explicitly scheduled by the user -- it is automatically scheduled by Fiber::suspend() and automatically un-scheduled by Fiber::resume() or Fiber::throw(). It's the fiber that runs between fibers :) Does that sound accurate? What's not clear to me is why the scheduling fiber needs to be distinguished from other fibers. If we want to stick with the general approach, why is Fiber::suspend($scheduler) not Fiber::transferTo($fiber), where $fiber would be the fiber serving as scheduler (but otherwise a normal Fiber)? I would expect that context-switching between arbitrary fibers would be both most expressive, and make for the smallest interface. The more limited alternative is to instead have Fiber::suspend() return to the parent fiber (the one that resume()d it). Here, the parent fiber effectively becomes the scheduler fiber. If I understand right, the reason why you don't want to use that approach, is that it doesn't allow you to call some AMP function from the {main} fiber, create the scheduler there and then treat {main} just like any other fiber. Is that correct? Regards, Nikita --000000000000ee8af905ba5ba55d--