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

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: Assigned +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: 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. Previous Comments: ------------------------------------------------------------------------ [2019-02-10 18:31:57] gadelat at gmail dot com Allright so I did try this, unfortunately when this function is used, script hangs on CTRL+C and cannot be killed, neither specified callback is executed. Then user can kill the script (as far as I see) only via task manager. ------------------------------------------------------------------------ [2019-02-10 17:14:47] ab@php.net You don't need to compile, just fetch a latest master snapshot here https://windows.php.net/downloads/snaps/master/ Thanks ------------------------------------------------------------------------ [2019-02-10 16:23:03] gadelat at gmail dot com That's greate news! Thank you for implementing this. Seems I'll wait for binary release though, I've not succeeded with compilation of PHP on Windows. ------------------------------------------------------------------------ [2019-02-10 03:17:42] ab@php.net @gadelat at gmail dot com, please check the latest master snapshots. The handling is as simple as the below code function handler($evt) { echo "Got CTRL+C event\n"; exit; } sapi_windows_set_ctrl_handler('handler'); run it and press CTRL+C. An UPGRADING note is to follow yet. Thanks. ------------------------------------------------------------------------ [2019-01-07 00:10:07] ab@php.net @nikic, yeah, EG(vm_interrupt) is also what is used for the timeout handling since 7.1 IIRC. I remember checking this to that times. It's impossible to pass the user data to the callback. As a consequence, the handling becomes tricky. Especially for the thread safe build. For the normal case, we don't start a new thread and the system sent CTRL+C is process wide. If something like pthreads or libuv is used - that'll need a magic, as potentially any thread could register a handler and i don't see a rationale which thread should then get an interrupt. Perhaps that should be the main thread always. When I was talking about interrupt, what I had in mind was a mechanism more similar to ticks, which would also need locking and the whole schmear. As an additional issue potential I see is, that one has to access the globals from another thread, whereby more than one signal could be scheduled and thus there might be race conditions. Btw. I think some atomic datatype should be used for the globals on Linux/UNIX as well. Anyway, thanks for checking. Let me revaluate this once more and do some research. 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