Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101812
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.163 cause and error)
MIME-Version: 1.0
In-Reply-To: <E48AB5EE-9C59-4564-A2C3-B56B84E86367@lvht.net>
References: <76EBF900-3BE8-4B60-9422-880A9754FCC4@lvht.net>
 <0DDFDACA-6322-461C-9D57-215E8C7D9CD0@trowski.com> <E48AB5EE-9C59-4564-A2C3-B56B84E86367@lvht.net>
Date: Thu, 8 Feb 2018 23:22:49 +0100
Message-ID: <CANUQDCgv2_2ZXRUqD-gVNpfiDxFkX--GagBxQf_OkB3W8dH1NQ@mail.gmail.com>
To: Haitao Lv <i@lvht.net>
Cc: Aaron Piotrowski <aaron@trowski.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="94eb2c146be2258e300564bada47"
Subject: Re: [PHP-DEV] [RFC] Fiber support (again)
From: me@kelunik.com (Niklas Keller)

--94eb2c146be2258e300564bada47
Content-Type: text/plain; charset="UTF-8"

>
> > - How do you determine when a fiber has returned? Looking at the source,
> it appears Fiber::status() must be used, comparing against constants.
> Separate methods similar to Generator would be better IMO. e.g.:
> Fiber::alive(), Fiber::suspended(), Fiber::running()
>
> Offering methods like Fiber::alive, Fiber::running makes no difference to
> check the Fiber::status() return value. This is just a style issue. And as
> a language feature,
> Fiber only offer the essential API and let other works to the user land.


The language should offer a sane API, not the absolute minimum required to
work for these things.


> > - What about throwing exceptions into a fiber?
>
> Currently does not support throw exception into the fiber. User land code
> could check
> the value of Fiber::yield and throw exception themselves. The Ruby's Fiber
> and Lua's
> coroutine also does not support such api as well.


And throw the exception where? That means async code with fibers can't
really handle errors?


>
> >
> > - Using Fiber::resume() to initialize the fiber and resume feels
> awkward. Separate methods again would be better here, perhaps
> Fiber::init(...$args) and Fiber::resume($send).
>
> All Fiber created with a suspended status. So make resume to do both the
> init and resume
> do make sense.
>

It does't make sense to me. Reading the example in the README and
understanding why the first resume() takes two arguments instead of one
took me quite some minutes.


> Please see Ruby Fiber API https://ruby-doc.org/core-2.2.0/Fiber.html.
>
> >
> > - What happens if the sub1() function in the RFC is invoked outside of a
> fiber?
>
> You will get a Fatal Error like
> Fatal error: Uncaught Error: Cannot call Fiber::yield out of Fiber
>
> > - I think a keyword here would be beneficial, even if it has a minor BC
> impact. Fibers could then be written like generators. `await` or `emit` as
> a keyword perhaps? This would be a less verbose API, feel less magical (a
> static method call that actually pauses execution feels out of place), and
> would allow Fibers to be returned from methods, named functions, etc with
> less boilerplate.
>
> Wishing this to be accepted by the community in the PHP 7.3, so no keyword
> is accepted.
> And if the community cannot accept, the Fiber can be still distributed as
> a standalone
> extension. So we cannot depend on a new keyword.


Right, if it's a standalone extension it can't use a new keyword, but as a
language feature it totally can.

Looking at the current README, there are two issues that must be completely
solved IMO before accepting this:

> Each Fiber has a separate 4k stack. You can use the fiber.stack_size ini
option to change the default stack size. You can also use the second
argument of Fiber::__construct to set the stack size on fly.

Resizing of the stack should happen automatically, just like generators
resize automatically.

> Fiber::yield cannot be used in internal callback

This also seems problematic and will make fibers quite less useful,
especially as these yields can happen anywhere down the stack.

Regards, Niklas

--94eb2c146be2258e300564bada47--