Req #77377 [Fbk]: No way to handle CTRL+C in Windows

From: 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

« previous php.bugs (#219480) next »