Req #77377 [Fbk]: No way to handle CTRL+C in Windows
| From: | ab@php.net | Date: | Mon, 11 Feb 2019 00:42:15 +0000 |
| Subject: | Req #77377 [Fbk]: No way to handle CTRL+C in Windows | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-219480@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=77377&edit=1
ID: 77377
Updated by: ab@php.net
Reported by: gadelat at gmail dot com
Summary: No way to handle CTRL+C in Windows
Status: Feedback
Type: Feature/Change Request
Package: Win32API related
Operating System: Windows 10
PHP Version: 7.2Git-2018-12-30 (Git)
Assigned To: ab
Block user comment: N
Private report: N
New Comment:
Thanks for sending the code. Yes, the select sticks in a blocking call, because it's given the
timeout of zero. The CTRL+C handler can't be called, as no further PHP code can be interpreted.
My suggestion you do similar to the following instead
while (true) {
$read = [$server];
$write = [];
$except = null;
stream_select($read, $write, $except, 0, 5000);
}
The basic idea - just occasionally return from the blocking calls to give the VM a chance to handle
the interrupt. It is one of the Windows specific points, as CTRL+* event doesn't automatically
cancel all the I/O nor it does anything else except invoking the handler function. Internally, the
VM interrupt is set, but because the select blocks, VM doesn't execute.
I'll think about a way to improve this, but I'm pessimistic there can be done much. One
could try to close the open descriptors, that might work, but for that one has to record all of them
which might be not doable.
Thanks.
Previous Comments:
------------------------------------------------------------------------
[2019-02-10 23:35:17] gadelat at gmail dot com
Here's reproducer
<?php
sapi_windows_set_ctrl_handler(function () {
echo 'shutting down';
exit(0);
});
$server = stream_socket_server('localhost:1337');
stream_set_blocking($server, false);
$read = [$server];
$write = [];
$except = null;
stream_select($read, $write, $except, null, null);
------------------------------------------------------------------------
[2019-02-10 22:14:46] ab@php.net
The sapi_windows_generate_ctrl_event() can be used to send CTRL+C to a child process opened by
proc_open(). It's otherwise same as one would press the keys.
Thansk.
------------------------------------------------------------------------
[2019-02-10 21:51:34] gadelat at gmail dot com
I did, but it uses sapi_windows_generate_ctrl_event which obviously might not match what happens
when ctrl+c is pressed.
------------------------------------------------------------------------
[2019-02-10 21:22:16] ab@php.net
Perhaps also check this test here http://git.php.net/?p=php-src.git;a=commitdiff;h=12bfd9a5f58c12b8f63011c130ec3bf6605ea33b#patch5
It's a bit more complex example, but it might give a better picture.
Thanks.
------------------------------------------------------------------------
[2019-02-10 21:13:56] ab@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
Thanks for checking. Please show the exact code. There are internal functions that would block the
execution, it would probably be same on other systems. Say a function like scanf(). The code like
this, which only uses the ZVM instructions should be ok.
function handler($evt)
{
echo "Got CTRL+C event\n";
exit;
}
sapi_windows_set_ctrl_handler('handler');
while(true) sleep(1); // checking the status
I'd need your exact code to tell more.
Thanks.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=77377
--
Edit this bug report at https://bugs.php.net/bug.php?id=77377&edit=1