Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116959
MIME-Version: 1.0
Reply-To: as@php.net
Date: Mon, 31 Jan 2022 21:35:15 -0500
Message-ID: <CAB-ec3SFfTXUfy5pJeo3nSOox-hxXyy4s1CVxTRTFpMW+97JHw@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000003ad88f05d6ebc1b7"
Subject: [RFC] Embedding multiple PHP engines in a single thread
From: as@php.net

--0000000000003ad88f05d6ebc1b7
Content-Type: text/plain; charset="UTF-8"

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)

--0000000000003ad88f05d6ebc1b7--