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: You don't need to compile, just fetch a latest master snapshot here https://windows.php.net/downloads/snaps/master/ Thanks Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [2019-01-05 17:21:00] nikic@php.net @ab: Isn't this the same as with pctnl signal handlers? We can't run PHP code there either, if for other reasons (not async signal safe). We handle this by registering a VM interrupt and thus delaying execution of the PHP signal handler. The same should be possible for Ctrl+C handling on Windows. All the groundwork in the VM is already there, we just need the interfacing to register the VM interrupt and then call the callback. ------------------------------------------------------------------------ [2019-01-05 17:11:33] ab@php.net Thanks for the report. Yes, it is a known issue. It is possible to catch ^C on Windows, but the handler is invoked in a separate thread. That means, it is not safe to run PHP code within the signal callback. If we would want to handle it, we'd have to insert some interrupts into the VM, which would slow down the execution. For now it's most likely a won't fix issue, I'd say. 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