@rmadsen-ks, thanks!@vmuriart,@davidanthoff,@yagweb,@filmor and@tonyroberts, please review this.

Codecov Report

Merging#450 intomaster willdecrease coverage by1.08%.
The diff coverage is66.66%.

@@            Coverage Diff             @@##           master     #450      +/-   ##==========================================- Coverage    77.4%   76.31%   -1.09%==========================================  Files          63       62       -1       Lines        5589     5569      -20       Branches      892      888       -4     ==========================================- Hits         4326     4250      -76- Misses        970     1026      +56  Partials      293      293

Continue to review full report at Codecov.

Legend -Click here to learn more
Δ = absolute <relative> (impact),ø = not affected,? = missing data
Powered byCodecov. Last updatefb84cd2...24ab0d1. Read thecomment docs.

@denfromufa, it seems some of the builds takes an extraordinary amount of time (59 min). Is there some way of canceling the builds so we dont have to wait for timeout?

@rmadsen-ks you may need to have access to CI build servers to cancel the builds, what do you think@vmuriart ?

@rmadsen-ks@filmor@vmuriart do you guys agree on removing the test for this behavior and merge pull request without the tests in CI? We can leave the original issue open, until proper testing is added.

Here is a user in need of this pull request:

#511

@denfromufa, unfortunately I dont have the bandwidth to figure how to make a unit test that works reliably. It turned out to be harder than expected to signal CTRL+C to an application running in the console on windows. Also I had decided to use CSharpProvider for runtime assembly generation, which I think is not compatible with .NET core, so that will probably need to move to Roslyn.

Do you have another idea of how to test this in an automated way?

In any case, the non-test part I think is low risk, but I suggest you do a bit of manual testing first anyway.

I did not understand the part about CSharpProvider :)

But the Ctrl+c keyboard interrupt can be emulated with this threading call:

thread.interrupt_main() # raises KeyboardInterrupt

More details in this new issue that I linked above.

@denfromufa,thread.interrupt_main() does not work in our case because we have a C# console application running embedded python code.

This is why I wanted to use CSharpProvider. I wanted to build a short console application that delays for a few s, but is interrupted by a keyboard interrupt. This I could also do by adding an assembly to the git repo, but I figured that would not be a popular decision. In any case, i have not been able to emulate CTRL+C on windows.

In my testing running _thread.interrupt_main() (python 3) as the embedded python script does not have the desired effect.

Let's continue work on this one in#724.