fix: support for timeouts with ZTS on Linux

[dunglas]

Closes https://bugs.php.net/bug.php?id=79464, #9738 and golang/go#56260.
Follows the plan described in this mail: https://externals.io/message/118859.

Currently, timeouts don't work at all on ZTS builds because signals are emitted by setitimer(), which is per-process. This patch fixes the problem on Linux by using timer_create() with SIGEV_THREAD_ID, as suggested by @nikic.

Also, this patch uses SIGIO instead of SIGPROFto prevent messing with profilers. This also improves the compatibility of PHP with Go (which is important for FrankenPHP). Why hijack SIGIO? Because there is no good way to choose this signal, and SIGIO is probably the safest signal in our case (SIGURG is already used internally by Go for its non-cooperative preemption feature).

This fix only works for Linux because Mac and BSD don't implement timer_create(). It may be possible to use libdispatch on Mac and FreeBSD to achieve something similar, but it's out of scope for this patch.

It's safe to merge this in 8.1 because the new system is only enabled for Linux ZTS builds, and timeouts are currently totally broken for this platform.

I wrote a test in FrankenPHP proving that this patch fixes the problem: php/frankenphp#128
I'm not sure how (and if it's necessary) to write a test for this in PHP. I could add an ad-hoc C program doing something similar as in FrankenPHP's test, WDYT?

TODO:

• add a ./configure argument to enable or disable Zend Timers

[arnaud-lb]

The choice of SIGIO seems reasonable based on the mentioned heuristics. The fact that the handler is able to ignore SIGIOs that was not caused by this specific timer is a good thing too (can we fallback to a previously set handler in this case?).

The first heuristic (being passed-through by debuggers) is much less relevant for this use-case than for Go's use-case - does it makes new choices available if we ignore this heuristic?

It could we worth it to comment about the reasons that led to SIGIO, so that we don't revert to SIGURG or SIGPROF in the future.

I'm not sure how (and if it's necessary) to write a test for this in PHP. I could add an ad-hoc C program doing something similar as in FrankenPHP's test, WDYT?

If the required effort is moderate, it would be worth it. You could add a function in ext/zend_test to execute a script in a separate thread.

Pinging @morrisonlevi@tstarling who showed interest

[tstarling]

Concept reviewed, looks like it should work. Needs a line-by-line close review but that can happen after some cleanups are done.

[dunglas]

The first heuristic (being passed-through by debuggers) is much less relevant for this use-case than for Go's use-case - does it makes new choices available if we ignore this heuristic?

If we want debuggers to handle the timeout signal, maybe could we also use SIGLOST or SIGSTKFLT. These signals are unused and unlikely to be triggered by real applications.

[dunglas]

@arnaud-lb@tstarling the patch is ready for another round of reviews, if you don't mind.

I'm not fond of this: https://github.com/php/php-src/blob/6feb7cd0b0b8e9c15d37bad6c3823c2bf276ed58/Zend/zend_timer.c#L90-L95

I would prefer throwing an error, but if I do, ext/opcache/tests/preload_parse_error.phpt fails: timer_delete() is called before timer_create() (I'm not sure why), and generating the error message segfaults on *filename = ZSTR_KNOWN(ZEND_STR_UNKNOWN_CAPITALIZED); in get_filename_lineno() (called by zend_error_noreturn()).

I'm trying to reproduce the FPM errors, but it's most likely related to the calls to fork(): children don't inherit timers (as you can see in the patch, I already fixed this issue for pcntl and ext/opcache.

[dunglas]

Tests are now green and the code looks good to me. Could you look if the last version of this patch is ok for you?

I'm hesitating on the naming: "Zend Timer" or "Zend Timers"?

[morrisonlevi]

FYI, I will take a look at this tomorrow. I think the plural "Zend Timers" is better, personally.

[morrisonlevi]

I haven't ran the code yet, this review is just from reading through it. I plan to check out the branch later today to test it under Apache Event MPM.

[dunglas]

@morrisonlevi it looks like this MPM uses both fork() and threads internally. We'll have to call zend_timer_create() in ap_hook_child_init() to have proper support in this SAPI because of the call to fork(). I'll update the PR.

[morrisonlevi]

@morrisonlevi it looks like this MPM uses both fork() and threads internally. We'll have to call zend_timer_create() in ap_hook_child_init() to have proper support in this SAPI because of the call to fork(). I'll update the PR.

What part of the sapi_module_struct does ap_hook_child_init correspond to? Do we already have a hook in the right place?

Edit: Ah, found it here: https://heap.space/xref/php-src/sapi/apache2handler/sapi_apache2.c?r=aef7d810#758.

[dunglas]

• Wall time is now used instead of CPU-time
• The API is now more consistent with the API of Zend Signals
• I fixed the Apache SAPI

My tests with Apache Event MPM were successful.

@morrisonlevi@arnaud-lb would you mind reviewing again? Thanks!

[arnaud-lb]

This looks good to me, but it's unfortunate that we have to handle forks.

EG(timer) is used only during execution, and is initialized in init_executor(), so we could let EG(timer) be initialized again by init_executor() if the fork executes a php script.

If we store the process id at the same time we initialize EG(timer), we can find whether the timer was created by the current process or not in zend_timer_shutdown().

pcntl_fork() would still need zend_timer_init(), though.

[arnaud-lb]

Thank you!

[morrisonlevi]

Thanks for your work on this!

[melroy89]

This is undocumented or not?