The following problem only occurs when I use ProactorEventLoop.  If I use 'asyncio.get_event_loop()' it exits normally, rather than infinite looping in IOCP land.

1. I run the attached 'bug.py' script in a DOS window.  It is a slightly modified version of the asyncio echo server example.
2. It reaches 'loop.run_forever()' and blocks.  I can make connections here and use it as an echo server.  Or make no connections.
3. I press Ctrl-C in the DOS window.  Nothing happens.
4. I do a raw connection with Putty and try some input.
5. 'run_forever()' exits and the script proceeds to the 'loop.close()' call.  Before this is invoked and the infinite loop entered, I see the script output '<ProactorEventLoop running=False closed=False debug=False>'.

At this point, the script locks up and never reaches the next line.  It can be interrupted with another Ctrl-C, and the following stack track is seen:

	Traceback (most recent call last):
	  File "bug.py", line 39, in <module>
		loop.close()
	  File "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python36_64\lib\asyncio\proactor_events.py", line 437, in close
		self._proactor.close()
	  File "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python36_64\lib\asyncio\windows_events.py", line 745, in close
		if not self._poll(1):
	  File "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python36_64\lib\asyncio\windows_events.py", line 673, in _poll
		status = _overlapped.GetQueuedCompletionStatus(self._iocp, ms)
	KeyboardInterrupt

The following code in 'windows_events.py:IocpProactor.close' is looping infinitely.

        while self._cache:
            if not self._poll(1):
                logger.debug('taking long time to close proactor')

Note that '_poll' does not actually return anything.

bug.py calls loop.run_forever() but nothing calls stops the loop. If you add loop.stop() to handle_incoming_connection(), the script exits properly as soon as a client connects and sends some data.

> 3. I press Ctrl-C in the DOS window.  Nothing happens.

This issue has been fixed by bpo-23057. So I qualify this issue as a duplicate of bpo-23057.