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

Edit report at https://bugs.php.net/bug.php?id=77377&edit=1 ID: 77377 User updated by: gadelat at gmail dot com Reported by: gadelat at gmail dot com Summary: No way to handle CTRL+C in Windows -Status: Feedback +Status: Assigned 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: 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. Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ 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