Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122117
MIME-Version: 1.0
References: <CADU7aovcatZ++PSg0Pt0-kXJH9Oe09N0jy5uXEoBYoRv6GeUwQ@mail.gmail.com>
 <3828a559-5dae-44d1-96ce-dff1a8b07c18@gmail.com> <CAPzBOBOx25-muH8BuMFJAHJp=L8wT_M-W8G-kk6fsPb9Lv_T0A@mail.gmail.com>
 <DABECB67-A138-4184-8E24-8CC9ED4802C4@gmail.com>
In-Reply-To: <DABECB67-A138-4184-8E24-8CC9ED4802C4@gmail.com>
Date: Fri, 5 Jan 2024 10:02:05 +0100
Message-ID: <CAPzBOBM0tYMfi5T9K4J3i-1yBg_n=ZyeziGoQBXTvGjXZEOsgg@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs
From: landers.robert@gmail.com (Robert Landers)

On Fri, Jan 5, 2024 at 8:47=E2=80=AFAM Rowan Tommins <rowan.collins@gmail.c=
om> wrote:
>
> On 5 January 2024 06:55:34 GMT, Robert Landers <landers.robert@gmail.com>=
 wrote:
>
> >I already said this, but to reiterate: I, personally, hear what you
> >are saying and largely agree with you; however, before we can really
> >have any kind of discussion on concurrent servers, we HAVE to address
> >the underlying issues that are missing from PHP. In PHP-src
>
> So, let's address them...
>
>
> > there are no such things as request objects
>
> This is a non-issue. As has been discussed already, it's perfectly fine t=
o have an event-based system where the event details are an associative arr=
ay, rather than a rich object.
>
>
>
> > There are no such things as event loops. There are fibers,
> > but absolutely no std-library i/o functions are using them
>
> This is what the bulk of Daniil's email is suggesting a way to improve.
>
>
> >We have a long way to go before those will be real things that we can
> >have a proper conversation about in the context of php-src.
>
> If we keep waiting to have the conversation, it will never happen.
>
> And if we start building brand new APIs like infrastructure for worker-mo=
de SAPIs, in ways that are fundamentally incompatible with async, we're jus=
t making more work for ourselves when we do get there.

I don't think they are fundamentally incompatible. If we look at
FrankenPHP's implementation, you pass a callback that gets called when
there is a request. This is the same as giving Swoole a callback to
call when a request is received, though the underlying implementation
might be very different. An event-loop doesn't matter here and what
gets passed to the callback is what we are discussing here.

The exact implementation (in php-src) matters, but only so far as what
php-src is capable of. Globals is how this works (atm) and changing
the signature of the callback is generally backwards compatible. For
example, if we start with only globals (no parameters), adding
parameters later once there are request objects/arrays/whatever, is
fine. Calling a callback with parameters when the function actually
doesn't accept any arguments, isn't even a notice
(https://3v4l.org/URj9b).

Changing the underlying implementation in php-src when there are
native fibers/event loops probably won't even change anything (since
that was exactly how they were designed).

But holding up the entire conversation because these things don't even
exist, seems like a pointless endeavor since they may not even pass
the RFC point (IIRC, getting an event-loop in PHP was a large part of
the reason fibers are the way they are because people were against an
event-loop at that time).

> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>


Robert Landers
Software Engineer
Utrecht NL