How to shut down a TCPServer serve_forever() loop?

[Chris Angelico]

On Tue, Nov 28, 2017 at 11:52 PM, Marko Rauhamaa <marko at pacujo.net> wrote:
> Chris Angelico <rosuav at gmail.com>:
>
>> On Tue, Nov 28, 2017 at 5:04 PM, Marko Rauhamaa <marko at pacujo.net> wrote:
>>> Seems to be one of the fundamental multithreading issues: each thread
>>> is blocked on precisely one event. Asyncio is more flexible: you can
>>> multiplex on a number of events.
>>
>> Not really, no. Unless select() counts as "precisely one event", of
>> course.
>
> Select() counts as asyncio.

Hmm. So what DOESN'T count as asyncio? Because I can use
multithreading with select, and in fact have done so on many
occasions. It's a perfectly normal Unix kernel function.

>> That's the normal way for a thread to block on multiple events on a
>> Unix system. Windows has its own approximate equivalent.
>>
>> Surprise, surprise, that's also how event loops often implemented.
>> Including ones used in packages like asyncio.
>
> The original poster's problem seems to be caused by blocking APIs that
> cannot be multiplexed using select(). A good many Python facilities are
> the same way.
>
> Such blocknoxious APIs are at the core of the multithreading programming
> paradigm.

Some things are fundamentally not multiplexable, at the lower levels.
(On Linux, and I believe most other Unix-like operating systems,
there's no non-blocking way to open a file, nor to gethostbyname.) How
do you propose to solve those in Python? Do you have one thread that
uses select() and another that does a blocking call? Do you spin off a
thread to do the blocking call and then have that thread notify your
main thread via a file descriptor?

I don't understand why you keep insisting that asyncio and threads are
somehow incompatible, or that they're a dichotomy. They're not. They
work together very nicely.

ChrisA