On Tue, Feb 1, 2022 at 3:36 AM 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
