This might need some more checking of places where the bailout is used and veryfying if it might have any impact on the apllication under wasm. We basically don't want to introduce something that will result to future bug and I would imagine that disabling bailout might be one of those things without a proper checking.

Yes, absolutely. Also, we will implement the bailout logic once we include setjmp/longjmp support.

what's the actual point of using FCGI if it's not re-using connection (if it's 0, then it closes the connection)? Why don't you just use plain CGI?

Updated the patch; fastcgi.c requires some changes because cgi_main uses certain symbols that come from fastcgi.c; and we are interested in php-cgi.

use tabs and not spaces (this is not the place where you indent with spaces so please all other cases as well)

Sorry, I am going to check everything, my editor is pretty stubborn at times.

just to make the CI job name shorter/nicer...

I would keep WASM32_WASI if that's fine, given that WASM64 be added eventually

All core tests (tests that does not require any unsupported extension) must pass or they must be exluded if they are expected to fail ATM.

setjmp/longjmp emulation

Fibers are core part of the PHP language since PHP 8.0 release. Can the support be added from the day zero?

All core tests (tests that does not require any unsupported extension) must pass or they must be exluded if they are expected to fail ATM.

Will exclude tests that don't apply on this platform in a next pass.

Fibers are core part of the PHP language since PHP 8.0 release. Can the support be added from the day zero?

We should look into that. If it's a prerequisite for this patch to land, then yes. If it's fine to iterate I'd prefer so, to not block the whole patch on smaller specifics, given the patch is already somewhat big.

Is there a reason why this is in its own file?

The idea was to be as less intrusive as possible with the existing tree, avoiding unnecessary ifdefs that might clutter existing files.

If you think there's a better way I'm fine with any proposal!

Does this need to be in a separate file? Separate files are a bit of a pain with autoconf because it require calling ./configure again.

Yes, same rationale as #10457 (comment), to be as less intrusive as possible.

I understand the ./configure re-run concern, but at this stage I think is better to keep them well separated, and as WASI evolves with future snapshots start merging with the main tree as things establish on upcoming wasi-libc versions.

Magic numbers are not a good idea. If WASM doesn't define LOG_NOTICE, then have a block somewhere else that defines this (and I suspect other constants) in one go.

This reads really odd - if WASI is active, you only use a forward declaration. I would rather do it like:

#ifndef PHP_WASI
static void php_shell_exec_ex(INTERNAL_FUNCTION_PARAMETERS) /* {{{
{
...
}
#else
static void php_shell_exec_ex(INTERNAL_FUNCTION_PARAMETERS) /* {{{
{
 php_wasi_shell_exec_ex(INTERNAL_FUNCTION_PARAMETERS_PASSTHRU);
}
#endif // PHP_WASI

And then have your new files implement the php_wasi_* variant(s).

But considering that doesn't do anything on WASI, this function should also just not even exist on that platform.

Again, these functions do nothing, so they shouldn't exist.