On Tue, Nov 28, 2017 at 11:52 PM, Marko Rauhamaa <ma...@pacujo.net> wrote: > Chris Angelico <ros...@gmail.com>: > >> On Tue, Nov 28, 2017 at 5:04 PM, Marko Rauhamaa <ma...@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 -- https://mail.python.org/mailman/listinfo/python-list
