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.

@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.

@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.

@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.

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.

You don't need to compile, just fetch a latest master snapshot here https://windows.php.net/downloads/snaps/master/

Thanks

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.

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.

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.

I did, but it uses sapi_windows_generate_ctrl_event which obviously might not match what happens when ctrl+c is pressed.

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.

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);

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.

@gadelat at gmail dot com, how is it going? :) Any other feedback?

Thanks.

stream_select is not in my expertise as I don't use it myself, just streamlined the hang to such peace of code in library. I have created issue https://github.com/amphp/amp/issues/262 and hopefully guys from AMPHP can take over this conversation. Outside of that, this works nicely

Cool, thanks for the info so far and for filing the issue. I'm still gonna document this and then close this one. I expect there'll be more reports closer to the 7.4 final, when more people start using this functionality.

Cheers.

Added UPGRADING notes. Closing this one for now. Please open separate tickets for any subsequent issues or ideas.

Thanks!

@Anatol: Under linux stream_select is comfortably aborted (signal being received) - is there any way to abort stream_select() from within Windows in that case?
At least the way it is now is a bit stupid - you don't want to rerun stream_select() too often, but also not wait x time units after pressing ctrl+c.
I don't mind if stream_select were calling select() repeatedly every 100 ms or such _internally_ on Windows. But I feel like this is not an userland responsibility.

@bwoebi Can you create new report please? This one is closed so apparently won't receive any more feedback. Thanks!