ter a request is a footgun is a non-business-logic requirement, an
exercise in functional purity that also reduces caching and concurrency
opportunities, as mentioned before.
A (somewhat bikesheeding, but this has been the vast majority of the posts on
this thread anyway) note is that await could also be made to accept an iterable
of futures, avoiding the use of Async\all combinators.
Regards,
Daniil Gentili.
ent context), you discourage people from using the “less easy” way
of spawning fibers through custom contexts, which will inevitably lead to
deadlocks.
I strongly believe that golang’s scopeless approach (which is the current
approach already used by async php) is the best approach, and there should be
no ways for users to mess with the internals of libraries that accidentally
spawn a fiber in the current scope instead of a custom one.
Regards,
Daniil Gentili.
onstruction but not during destruction, it would cause a deadlock (because it
would wait for an uncontrolled background task when exiting the block,
according the proposed functionality of wait_all).
Regards,
Daniil Gentili.
when initialising the library, and stopped
in __destruct when they are not needed anymore.
A coroutine context/scope a-la kotlin is fine, but it should absolutely not
have anything to await all coroutines in the scope, or else it can cause
deadlocks with the very common logic listed above.
Regards,
Daniil Gentili.
r on
initiative of the caller, that can be avoided by simply explicitly returning
and awaiting any spawned fibers.
Regards,
Daniil Gentili.
equences on the ecosystem.
I don't know what else to say on the topic, I feel like I've made myself clear
on the matter: if you still feel like it's a good idea and it should be added
to the RFC as a separate poll, I can only hope that the majority will see the
danger of adding such a useless keyword and vote against on that specific
matter.
Regards,
Daniil Gentili.
invoked within the block.
Libraries can full well handle cleanup of fibers in __destruct by themselves,
without a wait_all block forcing them to reduce concurrency whenever the caller
pleases.
It is, imo, a MAJOR FOOTGUN, and should not be even considered for
implementation.
Regards,
Daniil Gentili.
async {} blocks), or simply not get used at all
(because the main SAPI usecase listed explicitly does NOT need purity).
Regards,
Daniil Gentili.
ions from bubbling out into the exception handler).
Regards,
Daniil Gentili.
should handle cleanup of running fibers by themselves, on
their own terms, without externally imposed limitations.
> I would also note that the concept of parent and child fibers is also useful
> for other proposed features, such as cascading cancellations, and having
> environment-variable style inherited context data.
Yes, parenting does make sense for some usecases (indeed I already previously
proposed parenting just for cancellations), just not to offer a footgun that
explicitly limits concurrency.
Regards,
Daniil Gentili.
fiber, no one's forcing
you to use it, you can keep using everything in a single thread, single fiber,
no spawning.
Crippling async PHP with async blocks just because some libraries aren't ready
for concurrency now, means crippling the future of async php.
Regards,
Daniil Gentili.
for it, and after that happens, it will be even easier for users to use it.
(And actually, this is already the case, as fibers were added in 8.1, limiting
the userland scheduler makes no sense now that (thankfully!!) the cat is out of
the ba).
Regards,
Daniil Gentili.
and can be
handled by other means, without limiting concurrency.
Regards,
Daniil Gentili.
entation of concurrency.
Regards,
Daniil Gentili.
other common patterns like functional composition).
Again, take a look at how nicely golang handles concurrency with colorless
functions: php fibers weren't the first to do it.
Regards,
Daniil Gentili.
gt; *spawn/async* without worrying about its internals or modifying its code. The
> pros and cons of this approach are well known.
Loving this.
One might even consider to use the go keyaord along with async/spawn, to more
easily associate the operation with go's (gc)oroutines...
Regards,
Daniil Gentili.
ocks and making concurrency harder to
use.
I like and use immutability, but it has it limits, it should not be used
everywhere, and it should not be forced upon everyone just because someone is a
strong proponent of it.
Regards,
Daniil Gentili.
(Resent again as the other email has deliverability issues on the list).
ocks and making concurrency harder to
use.
I like and use immutability, but it has it limits, it should not be used
everywhere, and it should not be forced upon everyone just because someone is a
strong proponent of it.
Regards,
Daniil Gentili.
osals
that you do not really agree with.
Regards,
Daniil Gentili
—
Daniil Gentili - Senior software engineer
Portfolio: https://daniil.it <https://daniil.it/>
Telegram: https://t.me/danogentili
osals
that you do not really agree with.
Regards,
Daniil Gentili
—
Daniil Gentili - Senior software engineer
Portfolio: https://daniil.it <https://daniil.it/>
Telegram: https://t.me/danogentili
isolated between fibers.
> I haven’t thought about this possibility. But wouldn’t this break the FCGI
> contract?
I see no reason why it should break the contract, if implemented by isolating
the global state of each fiber, it can be treated as a mere implementation
detail of the (eventually new) SAPI.
Regards,
Daniil Gentili
—
Daniil Gentili - Senior software engineer
Portfolio: https://daniil.it
<https://daniil.it/>Telegram: https://t.me/danogentili
read (or in N
threads in an M-N M>N execution model) but its global state is entirely
isolated between fibers.
Regards,
Daniil Gentili - Senior software engineer
Portfolio: https://daniil.it <https://daniil.it/>
Telegram: https://t.me/danogentili
>> On 21 November 2024 10:48:46 GMT, Daniil Gentili > <mailto:daniil.gent...@gmail.com>> wrote:
>> >I speak for myself (and some others, as can be seen by pull requests on
>> >some FOSS projects, which made pull requests to account for this
>> &g
uded by the autoloader, so the end result is the same).
If functions could be autoloaded this edge case could be avoided without having
to add include guards, but alternatively, it might be a nice idea to simply
ignore the redeclaration of functions (like for classes), instead of not
preloading them at all.
Regards,
Daniil Gentili.
wrong with this behaviour, and it does what you expect it to
do.
Regards,
Daniil Gentili
> On 20 Nov 2024, at 22:22, Ilija Tovilo wrote:
>
> Hi everyone
>
> We recently received a bug report regarding the behavior of
> opcache_compile_file() [1]. The documentation spe
least without a support contract),
but all of these approaches may be reused if you or anyone else decides to
upstream FlowFusion (though I would love at least a @danog mention in the pull
request :)
Regards,
Daniil Gentili
—
Daniil Gentili - Senior software engineer
Portfolio: https://dani
It seems like the discussion on github has stalled...
Regards,
Daniil Gentili.
On 9/2/24 3:11 PM, Go Kudo wrote:
Hi Internals.
PHP currently does not provide official container images. Given that
DockerHub adequately maintains these and considering the maintenance
costs, we haven't felt the need to change the status quo.
However, the off
atching of a serious attack vector ASAP.
Regards,
Daniil Gentili.
manager, which brings us to square 1).
Regards,
Daniil Gentili.
ontaining *only* the bare source code, without
leaving to the user the choice to re-generate the build files, or use a
potentially compromised build script.
Regards,
Daniil Gentili.
In light of the recent supply chain attack in xz/lzma, leading to a backdoor in
openSSH (https://www.openwall.com/lists/oss-security/2024/03/29/4), I believe
that it would be a good idea to remove the huge attack surface offered by the
pre-generated autoconf build scripts and lexers, offered in
breaking a core feature of the language for one month (or more if a security
release delays the normal release cycle).
Also in general, I find it wrong that security releases should delay the normal
cycle.
Regards,
Daniil Gentili.
years? I'm almost certain it won't be.
No one is proposing to move the issue tracker to discord, slack or telegram:
those are messengers, and should not be used as support forums for such a major
language, mainly because they're non-indexable.
Regards,
Daniil Gentili
w away or to charge for
github, one of their biggest assets after Windows and OpenAI, PHP would have
bigger problems than RFCs being managed on the github issue tracker.
Regards,
Daniil Gentili.
ersations are easily accessible,
searchable and indexed by Google, with a much better UX than mailing lists.
Just my two cents, I still believe using mailing lists and an invite-only wiki
adds needless friction.
Regards,
Daniil Gentili.
ssages: mailing lists should not be used in 2024.
Regards,
Daniil Gentili.
randomly loose messages: mailing lists should not be used in 2024.
Regards,
Daniil Gentili.
iling list is nothing more than a redundant relic of the past.
Regards,
Daniil Gentili
a lot of
technical internals-related discussion is already using exclusively github
issues and pull request discussions, I believe that the mailing list is nothing
more than a redundant relic of the past.
Regards,
Daniil Gentili
Hi all,
I've opened voting for the final-by-default anonymous classes RFC:
https://wiki.php.net/rfc/final_by_default_anonymous_classes
Regards,
Daniil Gentili.
already require changes to better support it, using a new
API with a standalone request object/array instead of superglobals is not a
real issue.
Regards,
Daniil Gentili.
nd to present soon.
I hope that further discussion of a worker mode continues with an eye to the
future with native concurrency :)
Regards,
Daniil Gentili.
P. S. Just in case to avoid confusion for some, frankenphp does NOT add native
concurrency to php using goroutines, as control to the go event loop
Hi,
After the feedback received in the final voting thread for the final
anonymous classes RFC, I've created another RFC this time to make
anonymous classes final by default, here it is:
https://wiki.php.net/rfc/final_by_default_anonymous_classes
Regards,
Daniil Gentili.
--
PHP Inte
istake now.
Regarding the voting options, after feedback received in the last [RFC]
discussion thread from Nicolas Grekas:
>Hi Daniil,
>>> While I'm open to Proposal 1, which introduces final anonymous classes
>>> without breaking BC, Proposals 2 and 3 are a different s
inst it), could that be done
without restarting the discussion process?
Regards,
Daniil Gentili.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Hi all,
I've just opened voting for the "Change how JIT is disabled by default"
RFC @ https://wiki.php.net/rfc/jit_config_defaults.
Voting started now, and will run until December 18th 2023, 00:00 GMT.
Regards,
Daniil Gentili.
--
PHP Internals - PHP Runtime Development
Hi all,
I've just opened voting for the final anonymous classes RFC @
https://wiki.php.net/rfc/final_anonymous_classes.
Voting started now, and will run until December 18th 2023, 00:00 GMT.
Regards,
Daniil Gentili.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubs
Hi,
Pick an approach and put that up for a vote,
Picked the basic option of just adding final anonymous classes & edited
the RFC accordingly.
Thanks for the feedback!
Regards, Daniil Gentili.
Hi all,
Heads up, I'll move this RFC
(https://wiki.php.net/rfc/final_anonymous_classes) to voting status
tomorrow!
Regards,
Daniil Gentili.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Hi all,
Heads up, I'll move this RFC
(https://wiki.php.net/rfc/jit_config_defaults) to voting status tomorrow!
Regards,
Daniil Gentili.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
indeed some interest in a defer keyword for PHP, might
actually get to writing an RFC implementing the keyword itself this
weekend...
Regards,
Daniil Gentili.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
volt).
You probably want to use the EventLoop::delay function
(https://revolt.run/timers), or the async function
(https://amphp.org/amp#coroutines).
Regards,
Daniil Gentili.
Hi,
You probably want something similar to golang's defer keyword.
I intend to submit an RFC and PR for a defer keyword in PHP sometime in
the future.
Regards,
Daniil Gentili.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Hi again,
> Super on board with this
Sorry for top posting everyone, my bad, forgot to delete the rest of the
message :)
Regards,
Daniil Gentili
doubts I have about this proposal are the omission of static keywords
for functions and properties.
I understand this is inline with readonly classes, but I don't feel like static
is a keyword that should be omittable when declaring static methods and
properties.
Regards,
Daniil Gentili.
how the votes will go (I'm actually
curious myself :).
Regards,
Daniil Gentili.
It's clear that JIT won't work with
> "opcache.jit_buffer_size=0" in php.ini.
>
> Thanks. Dmitry.
Hi,
All done, updated both RFC and pull request :)
Regards,
Daniil Gentili
y way of finding out that JIT is not enabled even if you did enable it in
the config is running opcache_get_status.
Hope it's all fine by you, planning to get this merged by PHP 8.4.
Regards,
Daniil Gentili.
it=non-zero and jit_buffer_size=0, can I still turn it into a warning
though?
Regards,
Daniil Gentili.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
aker vote, voting favorably for only one
of the options would be allowed.
Regards,
Daniil Gentili.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
more than glad to receive some feedback!
Regards,
Daniil Gentili.
Hi all,
I would like to submit an RFC and PR to change a few INI defaults for
opcache, changing how JIT is disabled by default.
Here's the URL of the RFC: https://wiki.php.net/rfc/jit_config_defaults.
I'd more more than glad to receive some feedback!
Regards,
Daniil Gentil
Hi all,
I've created the RFC, I'd be more than glad to receive feedback:
https://wiki.php.net/rfc/final_anonymous_classes
Thanks,
Daniil Gentili.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Hi all, I've created the actual RFC:
https://wiki.php.net/rfc/jit_config_defaults
Regards,
Daniil Gentili.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
unlike tracing JIT, which does use runtime type
information).
Regards,
Daniil Gentili.
ng the deprecations RFC anyway to see if the
voting passes.
Kind regards,
Daniil Gentili.
oduce an error if any generic/extended type was
> encountered without being preloaded, but that poses a dilemma for libraries:
> either don't use the new types, or impose a requirement for applications to
> use preloading. I'm not convinced there's an easy compromise here.
No need to preload, just autoload at compile time like you said, and polyfill
missing classes that cannot be autoloaded.
Regards,
Daniil Gentili.
me types, or establishing stricter static rules that
do not match the existing behavior.
Well I'm all for stricter rules :)
Regards,
Daniil Gentili.
Hi,
> One thing I'm not sure about: What opcache optimizations would final enable?
Well for example, any JIT logic gated behind a check on ZEND_ACC_FINAL:
https://github.com/php/php-src/blob/master/ext/opcache/jit/zend_jit_trace.c#L4507
Regards,
Daniil Gentili
Hi,
> This deprecation appears to be sufficiently simple that it can likely be
> included in the bulk deprecation RFC for PHP 8.4:
>
> https://wiki.php.net/rfc/deprecations_php_8_4
That would be super nice, who should I ping before editing the page?
Regards,
Daniil Gentili
liant OS, it is not PHP's task to expose
the entirety of the POSIX standard functions: PHP's task is to provide a simple
to use language that also exposes some *useful* functions from the POSIX
standard, and posix_times does not fit the definition, in my opinion.
Regards,
Daniil Gentili.
lity which causes JIT bugs.
Personally I'm super excited for the possibility of introducing static
typechecking in PHP itself, partially because it also allows to easily and
cheaply implement generics.
Regards,
Daniil Gentili
arrow functions...)
Regards,
Daniil Gentili.
Hi,
This is precisely why I'm planning to submit the RFC to make the change
in PHP 8.4, which is when the new JIT will be introduced.
Regards,
Daniil.
On 10/18/23 08:52, Christian Schneider wrote:
Am 17.10.2023 um 19:46 schrieb Daniil Gentili :
I would like to submit an RFC and
would like to see this deprecated is not the fact that
it's returning a less precise value compared to getrusage, but rather
because it's returning a value that cannot be interpreted in any way
from pure PHP.
Regards,
Daniil Gentili.
On 10/18/23 09:00, Christian Schneider wrote:
Am
Hi, internals.
I'd like to create RFCs at least for final anonymous classes
(https://externals.io/message/121356) and a small tweak to JIT defaults
(https://externals.io/message/121359).
Please give me RFC Karma :)
Username: danog
Kind regards,
Daniil Gentili.
--
GitHub:
-src/pull/12425/files, any smaller multiple of
2 causes the buffer to fill up when running moderately sized projects
like Psalm or PHPStan).
What do you think?
Kind regards,
Daniil Gentili.
"stime_rusage"]=>
int(4994)
}
As you can see, with a system time of ~5 milliseconds, posix_times()
even returns 0, since the minimum duration that can be represented with
a 100 hertz clock (the default on most Linux platforms) is 10 milliseconds.
Waiting for feedback, kind regards,
Daniil Gentili.
[1]:
https://github.com/bminor/glibc/blob/69239bd7a216007692470aa9d5f3658024638742/sysdeps/unix/sysv/linux/ia64/getclktck.c
anonymous classes currently requires some hack-ish workarounds with
class_alias.
All in all, as per the title, I'd just like to add support for final
anonymous classes (new final class {}), without changing any existing
semantics.
What do you think?
Thanks,
Daniil Gentili.
Hi all,
I've submitted https://github.com/php/php-src/pull/11126 to add support
for final anonymous classes, though as noted by iluuu1994, it would
probably make more sense to just make all anonymous classes final by
default, what do you think?
Daniil Gentili.
--
PHP Internals
81 matches
Mail list logo
