[Python-Dev] Asynchronous context manager in a typical network server

[Guido van Rossum]

No, it just means Windows users should not try to catch signals on Windows.

Signals don't really exist there, and the simulation supporting only a few
signals is awful (last I tried ^C was only processed when the process was
waiting for input from stdin, and I had to use the BREAK key to stop
runaway processes, which killed my shell window as well as the Python
process).

If you want orderly shutdown of a server process on Windows, you should
probably listen for connections on a dedicated port on localhost and use
that as an indication to stop the server.

On Fri, Dec 18, 2015 at 11:29 AM, Glenn Linderman <v+python at g.nevcal.com>
wrote:

> On 12/18/2015 10:36 AM, Guido van Rossum wrote:
>
> I was opted to the signal module because `signal` documentation suggest
>> that
>> it alos supports Windows while asyncio documentation states that `loop.
>> add_signal_handler()` is UNIX only.
>>
>
> Unfortunately that's true, but using the signal module with asyncio the
> way you did is *not* safe. The only safe way is to use the
> loop.add_signal_handler() interface.
>
>
> Does this mean Windows users should not bother trying to use asyncio ?
>
> (I haven't yet, due to lack of time, but I'd hate to think of folks,
> including myself in the future, investing a lot of time developing
> something and then discover it can never be reliable, due to this sort of
> "unsafe" or "not-available-on-Windows" feature.)
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20151218/bd6442b3/attachment.html>