Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116969
MIME-Version: 1.0
References: <CAB-ec3SFfTXUfy5pJeo3nSOox-hxXyy4s1CVxTRTFpMW+97JHw@mail.gmail.com>
In-Reply-To: <CAB-ec3SFfTXUfy5pJeo3nSOox-hxXyy4s1CVxTRTFpMW+97JHw@mail.gmail.com>
Date: Tue, 1 Feb 2022 21:26:13 +0100
Message-ID: <CAF+90c-WO-iMqY+5mUPvCGY2u0srZ3cA8MkdGAewOFFGZbhSjg@mail.gmail.com>
To: as@php.net
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000005a099405d6fab791"
Subject: Re: [PHP-DEV] [RFC] Embedding multiple PHP engines in a single thread
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000005a099405d6fab791
Content-Type: text/plain; charset="UTF-8"

On Tue, Feb 1, 2022 at 3:36 AM <as@php.net> wrote:

> Hello internals,
>
> As you know, the PHP codebase makes heavy use of global variables. In ZTS
> builds, access to these globals are cleverly mapped to thread local storage
> via macros. To my knowledge, the limitation here is that there's no way to
> run multiple PHP engines in a single thread. (Please let me know if I'm
> missing something.)
>
> Naturally this is an extremely slim corner case. It would however unlock
> some interesting things like user-land zend_extensions and SAPIs without
> spawning threads needlessly. It would also enable one to build a
> coroutine-based SAPI[1].
>
> I'm curious if there's been any previous discussion around this, or if
> anyone has general feedback before I take a shot at this.
>
> My rough idea is to modify TSRM to support multiple
> `tsrm_tls_entry.storage` per thread, keyed by some caller-supplied id.
> Currently a thread-safe resource is accessed like
> `thread[thread_id].storage[resource_id]`. In my idea it would be
> `thread[thread_id].storage[storage_id][resource_id]` with some API function
> to push/pop `storage_id`. Any thoughts on that approach?
>
> Support for non-ZTS builds would be rad but would require much larger code
> changes.
>
> Feedback appreciated.
>
> Thank you,
>
> Adam
>
> [1] for example, to call into PHP concurrently from Go's green-threads
> (which may share a single OS thread)
>

In places we also use real thread-local storage (ZEND_TLS) -- actually,
this is the preferred method to manage global state if it is possible.
Nowadays TSRM exists essentially only to work around deficiencies in
cross-DLL TLS support on Windows. I don't think your scheme could extend to
those cases.

I'm not really convinced that it's worthwhile to invest effort in this
directly.

Regards,
Nikita

--0000000000005a099405d6fab791--