Re: [PHP-DEV] [RFC] Fibers
Hi Peter, > On Jan 8, 2021, at 3:03 AM, Peter Stalman wrote: > > I've been playing around with this for a bit, and I have some more questions. > I see you recently changed how the `FiberScheduler` works, making it `final` > and adding some "is" functions to match it more to a regular fiber. > > Since the `FiberScheduler` is itself also a fiber, why does it need to be a > separate class? Why did you choose to go this way and make it "special" > instead of not just making a regular fiber into a scheduler in userland. `FiberScheduler` is “special” because user code is not in control of suspending/resuming the underlying fiber, so `FiberScheduler` is a different class from `Fiber` without those methods. Internally a user fiber and scheduler fiber are similar, but I wanted to differentiate them in user code. `FiberScheduler` recently changed from an interface to a class because we discovered that automatically creating a scheduler fiber internally would make it difficult for adaptors or wrappers of a `FiberScheduler` to not create multiple internal scheduler fibers when there should only be a single scheduler fiber. The API largely works the same, but now the creation of the scheduler fiber is explicit in user code instead of done internally. This way adaptors or wrappers can return a single `FiberScheduler` instance. More code is required in user libraries, but offers greater flexibility. > Could you have two or more schedulers? You can have two or more schedulers in a single script. Only one can ever be running at a single time. > Could you get by without a scheduler and call a fiber inside a fiber > recursively? This design requires a scheduler fiber to be entered between suspending one user fiber and resume another user fiber. User fibers are designed to be independent. If two users fibers need to communicate, they should use something similar to Go’s channels to exchange data. > > Related to that, I noticed it was not possible to call `Fiber::this()` from > within the scheduler, why is that? Is it not just another fiber? Or is this > to prevent it from being passed to another scheduler? A scheduler fiber cannot be suspended or resumed by user code so it is not useful to get a reference to that fiber. > > Alternatively, going the other way, instead of making the scheduler a unique > class that needs to be passed around, why not go the more "traditional" PHP > route and pattern it after `register_shutdown_function(callable $callback, > mixed ...$args) : void`, `spl_autoload_register(callable $autoload_function = > ?, bool $throw = true, bool $prepend = false) : bool`, and those type of > functions? After all, isn't it just a callback too? Something like > `register_fiber_scheduler(callable $callback) : void`? > > This would remove the need for a special scheduler class and the need for > passing the scheduler back to the `Fiber::suspend()`. Each `suspend()` call > would bubble up through the registered scheduler callbacks. This would allow > competing schedulers to work nicer together, instead of one scheduler having > to finish before the higher up scheduler can run it's next loop. The scheduler to be entered is specific to the code calling `Fiber::suspend()`. Registering a global scheduler would require only a single scheduler to be used in a script. Only a single scheduler is entered on a call to `Fiber::suspend()`, not multiple schedulers. Registering schedulers or wrapping application code in boilerplate depending on the library being used is something this API is attempting to avoid. > > Either way, doesn't the fiber already know which scheduler it is in when it > suspends? No, a fiber can potentially use different schedulers at different suspend points. The scheduler that starts a fiber does not necessarily need to be the only scheduler that suspends the fiber. Hopefully that helps in understanding how the API works. Please take a look at how amphp v3 uses fibers in these examples https://github.com/amphp/amp/tree/v3/examples/pipeline or in react-fiber https://github.com/trowski/react-fiber/tree/master/examples where the Fiber API is handled by the library rather than “application” code. Cheers, Aaron Piotrowski -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Bundling ext/simdjson into core
Hey Máté, On Fri, Jan 8, 2021 at 1:20 PM Máté Kocsis wrote: > In the meanwhile I also realized that there are just too many unknowns > currently with this extension, so I cancelled my initial plans of adding > ext/simdjson as a core extension. > Since the majority of issues revolve around uncertainty/compatibility, is there perhaps a way for using the extension with an "overload `json_encode()` and `json_decode()` mode" (remember mbstring?), so that brave bleeding edge users can experiment with it as an opt-in replacement? That would certainly allow for some more precise field testing over the next few years. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
Re: [PHP-DEV] [RFC] Bundling ext/simdjson into core
Hi Jakub and Nikita, Thank you very much for your elaborate answers, you made good points. In the meanwhile I also realized that there are just too many unknowns currently with this extension, so I cancelled my initial plans of adding ext/simdjson as a core extension. I also agree that using the simdjson library as a backend would be a very interesting thing, so I'll try to experiment with this approach first. Slight incompatibilities between the backends would be very problematic for sure, so if we go this way then the implementations should be exercised by a definitive test suite like the one Nikita linked. Máté
[PHP-DEV] Re: PHP 8.0.1 Released!
On 08.01.2021 at 10:28, Christian Wenz wrote: >> The PHP development team announces the immediate availability of PHP >> 8.0.1. This is a security release. > > The release page (https://www.php.net/releases/8_0_1.php) states that it's a > bug fix release. I assume that's correct? PHP 7.3.26, 7.4.14 and 8.0.1 fix CVE-2020-7071, so all three releases are actually security releases (which also have regular bug fixes). Christoph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: PHP 8.0.1 Released!
On 08.01.2021 at 10:28, Christian Wenz wrote: >> The PHP development team announces the immediate availability of PHP >> 8.0.1. This is a security release. > > The release page (https://www.php.net/releases/8_0_1.php) states that it's a > bug fix release. I assume that's correct? PHP 7.3.26, 7.4.14 and 8.0.1 fix CVE-2020-7071, so all three releases are actually security releases (which also have regular bug fixes). Christoph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] RE: PHP 8.0.1 Released!
Hi Gabriel, > The PHP development team announces the immediate availability of PHP > 8.0.1. This is a security release. The release page (https://www.php.net/releases/8_0_1.php) states that it's a bug fix release. I assume that's correct? --Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Are there plans for ending support for 32-bit php? (year 2038 problem)
On Fri, Jan 8, 2021 at 3:47 AM tyson andre wrote: > Hi internals, > > 1. In 2038, `(new DateTime())->getTimestamp()` and other time apis such as > strtotime will start throwing "ValueError: Epoch doesn't fit in a PHP > integer" >on 32-bit php builds, where PHP's `int` type is 32-bits. >(other APIs will return negative 32-bit integers) >See https://en.wikipedia.org/wiki/Year_2038_problem > 2. Because PHP provides security support for 3 years, and many `*nix` OS > LTS releases extend it even longer, we should decide on what to do about >32-bit support well before 2038 (drop it or implement alternatives, and > alternatives seem unlikely to support a small fraction of hardware). > 3. Needing to support 32-bit PHP builds limits the APIs that can be > included in PHP, and slightly slows down development of PHP, PECLs, and > composer packages. > 4. I think PHP's documentation and tools should start discouraging > deploying new 32-bit builds, and give advance notice that it would be > removed (if it seems likely 32-bit support will be dropped.) > > Repeating the above points in more detail, > > 1) In the year 2038, many of 32-bit php builds' APIs dealing with unix > timestamps will stop working. > E.g. in 2038 on a 32-bit build of php, `(new DateTime())->getTimestamp()` > would throw "ValueError: Epoch doesn't fit in a PHP integer" instead of > returning an int, > when the time passes 0x7FFF. See https://bugs.php.net/bug.php?id=52062 > for details. > I'd consider throwing in getTimestamp to be the most reasonable solution, > given the return type of those methods is `int`, existing code may pass the > return value > to a function/property with real type int, etc. > > - > https://www.drupal.org/docs/system-requirements/limitations-of-32-bit-php > > 2) Although php's security support for a minor release lasts for only 3 > years, > some `*nix` OSes will make a best effort at unofficially backporting > patches to php for the lifetime of that OS's LTS release, > so we could potentially see 32-bit builds for ~10 years (not sure what > 32-bit distros there will be in 2028. This number is a guess.) > - on **desktop** oses, the main use of 32-bit packages on 64-bit hardware > seems to be for supporting code released for only one architecture, > e.g. > https://ubuntu.com/blog/statement-on-32-bit-i386-packages-for-ubuntu-19-10-and-20-04-lts > - Many WordPress servers still run php 5.x. > - If applications running on an OS with 10 years of php support computed > dates that are a year in the future, > it'd be useful to prepare 11 years in advance. > There are 17 years until 2038. > > Hardware that only has 32-bit support is still running on a small fraction > of machines being sold (e.g. cheap laptops), > and 32-bit hardware may last decades after they were manufactured, > but is hopefully a tiny fraction of server/consumer hardware still being > manufactured in 2021. > I don't know of 32-bit php running in embedded systems or IoT devices, but > haven't looked. > - Aside: It is possible to install a 32-bit only OS on hardware supporting > 64-bit architectures, > https://www.backblaze.com/blog/64-bit-os-vs-32-bit-os/ > > If PHP's maintainers decide to drop support for 32-bit builds in a future > major/minor release, it would be useful to give users advance notice, > so that they can factor this into decisions on hardware and OSes to use > for deploying php in servers or developing locally. > > 3) Needing to support 32-bit PHP builds limits what can be done in the > language, and slightly slows down development of PHP, PECLs, and composer > packages. > > Additionally, continuing to provide 32-bit support constrains what APIs > can be provided by the language. > In most cases this isn't an issue, but this came up with > `PRNG->next64BitInt()` being impractical practical in a recent proposal: > https://externals.io/message/112525#112722 > > - 32-bit installations do reduce the memory usage and installation size of > php slightly, > but those installations would have problems with the 2038 problem and > supporting use cases that require more than 2-4GB of free memory. > - PECLs and composer packages are generally not tested as thoroughly on > 32-bit builds. > Maintainers may be less responsive if they're personally unaffected, or > don't already have 32-bit builds installed, or don't know from the bug > report that 32-bit php was used. > - The PHP interpreter (Zend/zend_vm_def.h, etc.) and JIT have different > implementations for 32-bit builds, complicating development of php itself. > Hypothetically that could lead to bugs getting released and contributing > to the VM being harder to do, but in practice it doesn't seem to be a large > issue. > > In comparison, other languages I've used would have an easier time > continuing to support 32-bit builds past 2038. > > - Python and Ruby have arbitrary-precision numbers. > - In Java, `int` is 32-bit, and `long` is 64-bit. > - Golang and C and rust have
Re: [PHP-DEV] [RFC] Fibers
Hi again Aaron,
I've been playing around with this for a bit, and I have some more
questions. I see you recently changed how the `FiberScheduler` works,
making it `final` and adding some "is" functions to match it more to a
regular fiber.
Since the `FiberScheduler` is itself also a fiber, why does it need to be a
separate class? Why did you choose to go this way and make it "special"
instead of not just making a regular fiber into a scheduler in userland.
Could you have two or more schedulers? Could you get by without a
scheduler and call a fiber inside a fiber recursively?
Related to that, I noticed it was not possible to call `Fiber::this()` from
within the scheduler, why is that? Is it not just another fiber? Or is
this to prevent it from being passed to another scheduler?
Alternatively, going the other way, instead of making the scheduler a
unique class that needs to be passed around, why not go the more
"traditional" PHP route and pattern it after
`register_shutdown_function(callable $callback, mixed ...$args) : void`,
`spl_autoload_register(callable $autoload_function = ?, bool $throw = true,
bool $prepend = false) : bool`, and those type of functions? After all,
isn't it just a callback too? Something like
`register_fiber_scheduler(callable $callback) : void`?
This would remove the need for a special scheduler class and the need for
passing the scheduler back to the `Fiber::suspend()`. Each `suspend()`
call would bubble up through the registered scheduler callbacks. This
would allow competing schedulers to work nicer together, instead of one
scheduler having to finish before the higher up scheduler can run it's next
loop.
Either way, doesn't the fiber already know which scheduler it is in when it
suspends?
I think this would go along with simplifying it and keep the implementation
broad to allow for various userland implementations (as mentioned, such as
amphp and reactphp). But it probably doesn't simplify the C
implementation...
Anyways, something like this?
$fiber = Fiber::this();
$callbacks = [
fn() => $fiber->resume("Test"),
];
register_fiber_scheduler(function() use ($callbacks) {
foreach ($callbacks as $callback) {
$callback();
}
});
$value = Fiber::suspend();
echo "After resuming main fiber: ", $value, "\n"; // Output: After
resuming main fiber: Test
Btw, this is just me vomiting my thoughts, I don't know enough about fibers
to design it one way or the other, but I hope to understand it more as well
as give a few different perspectives on it.
Thanks,
Peter
On Thu, Dec 17, 2020 at 8:30 AM 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 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
>
> 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.
>
> Aaron Piotrowski
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
