A Hitchhiker’s Guide to Asynchronous Programming

Just create a new pool and close the previous one, depending of the system load.

You’re sending the poor newbie on a journey of self-discovering of picklable-non-picklable, passing of arguments back and forth, working with Queues (which have well-known yet undocumented race conditions), missing exception stack traces due to dead processes and all sorts of useless garbage they don’t need to know about.

Also what exactly would that newbie be building that starts and stops threads depending on the system load? What kind of a contraption is that? What are you doing?

Finallizing all of the above: under the circumstance you mentioned, you should check whether you have just seriously over-architected the solution.

https://styleguide.mailchimp.com/voice-and-tone/ (previously voiceandtone.com)

https://mkaz.blog/misc/notes-on-technical-writing/

https://spin.atomicobject.com/2014/09/09/never-use-the-word-...

https://developers.google.com/tech-writing/overview

I think the problem they're printing out isn't the writing, it's the content. Coroutines and event loops are two independent concepts. And scheduling tasks cooperatively in userspace is another concept still. You've got three different concepts: coroutines, event loops, and cooperative multitasking; and you're saying they're the same thing.

TL;DR - implementing parallel code in Python means using multiprocessing as opposed to multithreading, but it depends on if you're CPU bound or I/O bound.

The GIL prevents more than one instance of the python interpreter from running _per processor_. This effectively means you can only have one Python thread per processor running at a time, which is frustrating because that kinda defeats the point of threading. However, most python programs aren't CPU bound, but I/O bound. For those programs, using the python multithreading abstraction is fine; CPUs are fast enough to do context switches while one thread waits for data, etc. For CPU bound tasks, the solution is to write using the multiprocess module; each process spun up has its own interpreter and its own GIL. Things have changed somewhat with Python 3, where there are some more robust internal scheduling tools inside the multithreading module, but the rule of thumb still stays the same.

Python always could use multiprocessing to do parallel processing leveraging several CPU.

However, it became especially easy with Python 3.2 (10 years ago) which introduced the ProcessPoolExecutor (https://docs.python.org/dev/library/concurrent.futures.html#...):

    import random
    import time
    from concurrent.futures import ProcessPoolExecutor, as_completed


    def hello():
        seconds = random.randint(0, 5)
        print(f"Start blocking for {seconds}s")
        time.sleep(seconds)
        print(f"Stopped blocking after {seconds}s")
        return seconds

    if __name__ == "__main__":

        with ProcessPoolExecutor(max_workers=2) as exec:

            a = exec.submit(hello)
            b = exec.submit(hello)

            for future in as_completed((a, b)):
                print(future.result())

The same exact same API exist for thread BTW. I don't think a tutorial should introduce you to concurrency using manual process/thread management any more. I makes no sense to me.

You may note that multiprocessing still eats more RAM than with typical Go/Rust code since max_workers=n means n+1 Python VM spawing but on modern servers you don't really feel it. That's what most WSGI setup do anyway.

Now, before 2019, there was one more use case that wasn't served well: how do you share some computation between isolated processes that need to communicate to make their work ? Typical use case was people using numpy or pandas crunching numbers that depended on each others. Indeed, communicating between processing using piping is expensive given the cost of message passing serialization.

However, in the previous Python release (3.8), we introduced a mechanism to share memory for almost free (https://docs.python.org/3/library/multiprocessing.shared_mem...):

    from multiprocessing.managers import SharedMemoryManager

    with SharedMemoryManager() as smm:
        sl = smm.ShareableList(name="unique_name", range(2000))

The sl object can then contain int, float, bool, str, bytes and None and its reference can be shared among processes. Each item can be deleted and replaced. You an also get an hold on sl by using the "unique_name" if you don't have the reference at hand.

There is a raw ShareableMemory object for stuff like numpy/pandas array buffers if this is your main concern.

GIL is a problem only if you're CPU bound. For I/O bound problems Python can get you a long way.

I think the syntax, `yield from`, and `@coroutine` are two things. `async def` + `yield from` means we delegate generator to another generator. Therefore, in the async function, using `yield from` is equal to declare an asynchronous generator function.

However, using `@coroutine` + `yield from` means we transform a generator into a generator coroutine. Because a generator is a form of coroutine, in Python 3.4, `@coroutine` turns a function or a future into a generator function. Note that if a function is a generator function, `@coroutine` does not do anything. Based on the document, Python recommends using `async def` instead of `@coroutine` to declare a coroutine because `@coroutine` will be removed in Python 3.10.