This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author zach.ware
Recipients BreamoreBoy, asvetlov, pitrou, r.david.murray, tim.golden, zach.ware
Date 2014-07-22.19:50:32
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
It looks like we have a bit of a mess here.  2.7 has a return there (and thus doesn't fall back to TerminateProcess if GenerateConsoleCtrlEvent fails), added 40 commits after the initial implementation in b1c00c7d3c85, but 3.x was never changed so 2.7 and 3.x have behaved differently from the the time it was implemented.  Which version is right, or is it too late to change either one and 3.x should just remove the unused error setting?  An interesting possibility might be to convert the signal.CTRL_* values to an enum, and use that as a way to distinguish between ``0`` and ``signal.CTRL_C_EVENT``.  I suspect that might become rather hairy, though.

Either way, I don't think os.kill can promise much more than "try to make the specified process die" on Windows; signals are just so crippled on Windows that that's about all you can do with them anyway.  It might not hurt for the docs to try to make that clearer.
Date User Action Args
2014-07-22 19:50:32zach.waresetrecipients: + zach.ware, pitrou, tim.golden, r.david.murray, asvetlov, BreamoreBoy
2014-07-22 19:50:32zach.waresetmessageid: <>
2014-07-22 19:50:32zach.warelinkissue14484 messages
2014-07-22 19:50:32zach.warecreate