curl and other native libraries block pcntl async signal propagation

[olsavmic]

Description

The following code:

<?php

pcntl_async_signals(true);

$handler = function() {
	echo 'HANDLER CALLED' . PHP_EOL;
	pcntl_alarm(1);
};

pcntl_signal(SIGALRM, $handler);
pcntl_alarm(1);

while (true) {
    $ch = curl_init();
    //curl_setopt($ch, CURLOPT_NOPROGRESS, false);
    //curl_setopt($ch, CURLOPT_PROGRESSFUNCTION, function() {});
    curl_setopt($ch, CURLOPT_URL, 'http://localhost/timeout.php');
    curl_exec($ch);
    curl_close($ch);
}

Gives following output:

Request started
HANDLER CALLED
Request done

But I expected this output instead:

Request started
HANDLER CALLED
HANDLER CALLED
HANDLER CALLED
HANDLER CALLED
HANDLER CALLED
HANDLER CALLED
HANDLER CALLED
HANDLER CALLED
HANDLER CALLED
Request done

PHP main thread is blocked during the entire request, the handler is called only after that. This behaviour renders pcntl_async_signals unusable for most workloads (eg. sending heartbeats to keep connections open during long running operations). The issue is not restricted to SIGALRM only, it applies to all signals.

Such behaviour is not documented anywhere (including the RFC https://wiki.php.net/rfc/async_signals) yet the same problem actually applies to other native libraries like PDO/mysqli,... (see already reported issue for mysqli https://bugs.php.net/bug.php?id=81515)

If this is expected behaviour, it must be documented as right now it seems like the only RELIABLE way to implement specific features but it behaves unpredictably with the use of 3rd party libraries and it's very hard to debug.

Adding both curl_setopt($ch, CURLOPT_NOPROGRESS, false); and curl_setopt($ch, CURLOPT_PROGRESSFUNCTION, function() {}); fixes this particular issue but it's an undocumented required configuration and most likely just a side-effect.

---

Example of PDO query blocking:

<?php

pcntl_async_signals(true);

$handler = function () {
	echo 'Handler called';
	pcntl_alarm(1);
};

pcntl_signal(SIGALRM, $handler);
pcntl_alarm(1);

$conn = new PDO('mysql:host=localhost;dbname=test', 'root', 'admin');
$conn->query("SELECT SLEEP(10)");

PHP Version

8.1, 8.0

Operating System

Debian Buster, MacOS

[cmb69]

The RFC states: "Registered signal handlers are going to be called at some points during user script execution without any overhead." If you're calling an internal function which does not call back to the user script, no signal handling is supposed to happen. At least that is how I understand it.

I'm leaving that to someone with a POSIX background to confirm (in which case this is a doc issue), or to refute.

[iluuu1994]

I took a quick look. Like @cmb69 suspected, pcntl_interrupt_function (which calls the given userland functions) is called by the zend_interrupt_helper in the VM, which in turn gets triggered in the VM between instructions with pcntl_async_signals(true). The documentation for pcntl_async_signals could definitely be improved. There's no mention on when the signals are going to be handled.