php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #77377 No way to handle CTRL+C in Windows
Submitted: 2018-12-30 17:14 UTC Modified: 2019-01-07 00:11 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: gadelat at gmail dot com Assigned: ab (profile)
Status: Assigned Package: Win32API related
PHP Version: 7.2Git-2018-12-30 (Git) OS: Windows 10
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: gadelat at gmail dot com
New email:
PHP Version: OS:

 

 [2018-12-30 17:14 UTC] gadelat at gmail dot com
Description:
------------
There is currently no way how to handle CTRL+C with PHP in Windows. This makes it the only scripting language I know that cannot handle this and pretty bad choice for writing cross platform compatible CLI applications.

- handler registered via register_shutdown_function is not called for CTR+C
- pcntl_signal relies on PCNTL extension which isn't available on Windows 

Notice that I am trying to avoid word "signal" here as you may argue there are no signals in Windows. Developer still needs a way how to handle CTRL+C press of end user. 

This is important eg. for running cleanup tasks, as not even PHP's tmpfile() cleanup logic is executed when user aborts program via CTRL+C.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2019-01-05 17:11 UTC] 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.
 [2019-01-05 17:21 UTC] 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-07 00:10 UTC] 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-07 00:11 UTC] ab@php.net
-Assigned To: +Assigned To: ab
 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Wed Jan 16 13:01:25 2019 UTC