I don't think you need the threads. 1. If your tasks are I/O bound, coroutines are a safer way to do things, and probably even have better performance;
2. If your tasks are CPU bound, only multiple processes will help, multiple (Python) threads do not help at all. Only in the special case where the CPU work is mostly done via a C library[*] do threads help. I would recommend using multiple threads only if interacting with 3rd party code that is I/O bound but is not written with an asynchronous API, such as the requests library, selenium, etc. But in this case, probably using asyncio.Loop.run_in_executor() is a simpler solution. [*] and a C API wrapped in such a way that it does a lot of work with few Python calls, plus it releases the GIL, so don't go thinking that a simple scalar math function call can take advantage of multithreading. On 18 April 2016 at 19:33, cr0hn cr0hn <cr...@cr0hn.com> wrote: > Hi all, > > It's the first time I write in this list. Sorry if it's not the best place > for this question. > > After I read the Asyncio's documentation, PEPs, Guido/Jesse/David Beazley > articles/talks, etc, I developed a PoC library that mixes: Process + > Threads + Asyncio Tasks, doing an scheme like this diagram: > > main -> Process 1 -> Thread 1.1 -> Task 1.1.1 > -> Task 1.1.2 > -> Task 1.1.3 > > -> Thread 1.2 > -> Task 1.2.1 > -> Task 1.2.2 > -> Task 1.2.3 > > Process 2 -> Thread 2.1 -> Task 2.1.1 > -> Task 2.1.2 > -> Task 2.1.3 > > -> Thread 2.2 > -> Task 2.2.1 > -> Task 2.2.2 > -> Task 2.2.3 > > In my local tests, this approach appear to improve (and simplify) the > concurrency/parallelism for some tasks but, before release the library at > github, I don't know if my aproach is wrong and I would appreciate your > opinion. > > Thank you very much for your time. > > Regards! > -- Gustavo J. A. M. Carneiro Gambit Research "The universe is always one step beyond logic." -- Frank Herbert
