On Wed, Jul 24, 2024, at 13:54, Pierre Joye wrote: > Hi Rob, > > > On Wed, Jul 24, 2024 at 3:17 PM Rob Landers <[email protected]> wrote: > > > > Hello internals, > > > > Last night I went down a rabbit hole with Frankenphp: > > https://github.com/dunglas/frankenphp/pull/933 > > > > It isn't 100% clear to me what values `ts_resource(id)` holds and if it > > needs to be freed/allocated per request or per thread. The performance > > impact is huge to reallocate on every request (mostly due to the global > > mutex during allocation). Is anyone familiar with this and could help > > reviewing the changes there? > > I suppose you already looked, but if not, maybe it gives you some > direction(s). > > The key part is kind of documented here: > > https://github.com/php/php-src/blob/8e93eb2e79cea5fcca6769b46a429de042660da9/TSRM/TSRM.c#L417 > > tsrm knows nothing about requests but only threads.Its jobs are about > threads data. > > A good start (surely already looked) are apache and litespeed (or > embed) for php8, however besides the API names change, the behavior or > goals of each ts_ or tsrm_ functions remain the same as what we had > with 5.x. One with a very similar modus operandi than Franken was > ISAPI for IIS. Mind the names changes, dapt to php8's new names (and > some behaviors) but the basics and core flows have been kept. > > If you know (~) how many threads franken is going to need, tsrm allows > you to preallocate the rsc slots using tsrm_startup_ex. It uses > tsrm_startup, a more powerful version, which lets franken define how > many rsc per thread will be preallocated. I suppose that could help a > bit performance wise: > > https://github.com/php/php-src/blob/8e93eb2e79cea5fcca6769b46a429de042660da9/main/main.c#L2716C13-L2716C25 > > As per the last question, about when to free them: > tsrm_shutdown (franken shutdown) will free all rsc > > When a thread is detached (franken kills it for example), > ts_free_thread needs to be called to kill its rsc. They will be freed > anyway too but good to be clean. > > The tsrm resource management will also automatically purge orphan rsrc > (f.e. when a thread dies unexpectedly and ts_free_thread could not be > called). > > Long story short, the TSRM API is very flexible, how and when you > alloc/free rsrc is basically up to you. It is possible to keep some > around in the root thread (and be used in other threads, given the > root thread id is known (can be 0 or else depending how franken > managed them. > > I hope it helps and did not say too many outdated/wrong explanations :). > > Btw, Welting rewrote that part with Dmitry back then to fix long > standing issues (and drop TSRM_LS/DC/CC uses), not sure if he is still > around but he may help. > > Best, > -- > Pierre > > @pierrejoye | http://www.libgd.org >
Hey Pierre, Thank you! This helps tremendously. > A good start (surely already looked) are apache and litespeed (or > embed) for php8, however besides the API names change, the behavior or > goals of each ts_ or tsrm_ functions remain the same as what we had > with 5.x. One with a very similar modus operandi than Franken was > ISAPI for IIS. Mind the names changes, dapt to php8's new names (and > some behaviors) but the basics and core flows have been kept. I looked at litespeed but not apache, so I will look to that as well. > If you know (~) how many threads franken is going to need, tsrm allows > you to preallocate the rsc slots using tsrm_startup_ex. It uses > tsrm_startup, a more powerful version, which lets franken define how > many rsc per thread will be preallocated. I suppose that could help a > bit performance wise: The number of threads are static (at least for now), so we should def do this. > Long story short, the TSRM API is very flexible, how and when you > alloc/free rsrc is basically up to you. It is possible to keep some > around in the root thread (and be used in other threads, given the > root thread id is known (can be 0 or else depending how franken > managed them. Ah, so this is where I was getting confused. It's unclear what the "id" is and what it is used for. For example, I see the engine has a couple of ids (compiler/execution) but I'm unclear what the sapi should be doing with them. Should these "ids" be different per thread, or is it just an arbitrary key? — Rob
