Go and TSRM: a marriage in memory management

[withinboredom]

I think after digging into the shenanigans in #1080 and in #1086, it is clear that there are probably some other issues involving memory management between Go and PHP. Ideally, we can somehow "hook into" or even replace TSRM with one that can work collaboratively with Go.

This might even allow us to get rid of C threads altogether, and manage everything in Go.

The main issue is how to implement said "hooks." We could use function pointers in TSRM that can be replaced before booting PHP or when registering the sapi module. That is probably the simplest solution, to be honest.

What are your thoughts?

[dunglas]

Doing something like this has been on my to-do list since the creation of FrankenPHP, and using function pointers is also what I had in mind. It would be great if we could make progress on this!

To get rid of C threads completely, we'll also have to get rid of the signals used by the PHP engine, which are not compatible with the Go execution engine. They are mainly used for timeout management. We'll probably have to create hooks to delegate timeout management to Go's time functions, which don't use signals.

Perhaps we should discuss this first on PHP internals, as we'll need to expose a new ABI to enable these extension points.

[withinboredom]

I think most (if not all) of the TSRM changes can be done without changing the ABI and only adding new, optional things. Signals and environmental stuff, not so much. The TSRM changes might be a good starting point and relatively straightforward after digging into it.

[AlliBalliBaba]

What would this look like? Would the thread coming from Caddy's ServeHTTP directly invoke PHP by grabbing or creating a 'non busy' TSRM instance?

[withinboredom]

It would basically allow PHP to run entwined with Go. Go doesn't have a concept of "thread local" but PHP does and relies on it quite a bit via TSRM. In other words, allowing PHP to run not attached to any specific thread.

[AlliBalliBaba]

Very interesting, so it would still be a pool of these TSRM storages, but they wouldn't be restricted to a thread. I wonder if that could also potentially allow running php functions concurrently through a goroutine (however efficient that would be with Cgo in the mix)

[withinboredom]

I would think so. In other words, all the power of go-routines in php.

[AlliBalliBaba]

Would there be any way to test this without completely recompiling PHP?

[withinboredom]

Probably not, and it will be reminiscent of the old days where we would run a custom branch of php until changes are merged in (this is how frankenphp used to work). Since it is a technical change, we don't need an RFC and can open the branch on 8.2, then rebase it on later versions. Though, I haven't checked on the end-of-support date for 8.2, which may be soon.

[withinboredom]

I've started digging into TSRM and it's implementation. Went ahead and implemented the r/w locks: php/php-src#16565

Dunno when that will be merged, though. Soon I will have a list of possibilities (probably early next month).

[AlliBalliBaba]

I'm currently working on an experimental branch that allows dynamically starting and stopping workers since I think we will need the additional control over PHP from the go side.
This works pretty well - apart from a weird memory corruption that only happens when starting a PHP thread right after having stopped another thread. Are there better ways to debug these issues apart from looking at the backtrace of the core dump with gdb?

[AlliBalliBaba]

Nvm, I think it's best to get there in small steps. I have a thread-refactor PR in the works, but I'll probably wait until my github actions are back before pushing it.

[dunglas]

Maybe could you use temporarily a new github account?

[AlliBalliBaba]

Would you make that account a maintainer as well? So I can trigger actions on current branches: https://github.com/Alliballibaba2

[dunglas]

@AlliBalliBaba I've sent an invite to your second account