Thank you for sharing this excellent resource! You make a great point—searching for "modern C++" often surfaces C++11-era content, while newer standards have already deprecated some of those "modern" practices. That's exactly why I created this project: to continuously update and document contemporary best practices as the language evolves. I'll definitely check out the linked rant for ideas to incorporate. Thanks for the suggestion!
I agree with you. We should use a reliable library, as you said. The primary purpose of this article is to help people understand what a coroutine and an event loop are. Therefore, programmers can use asyncio API fluently without misuse.
However, I don't think use threads/processes is a bad idea. A pool gives you a constrain to utilize threads/processes, but sometime we may want to adjust the number of threads/processes based on system load. Under this circumstance, using a pool is not the best choice.
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.
I understand you are worried about newbies misuse APIs. You remind me that I should add a warning to inform the sample code in this article should not use in programs. Thanks.
Also, I did not advocate a newbie should start and stop threads by themselves. I want to say I agree that we should use high-level APIs in most cases, but, in some cases, we may need to use low-level APIs to achieve our missions. I am unwilling to limit what kind of APIs should use. In my opinion, like you said: "you have just seriously over-architected the solution," we should be careful to use APIs. Even though high-level APIs are safer, programmers may misuse them.
I think this is not an excellent solution. You have to wait for all threads finish. I agree that we should use high-level API in most of the time, but, in some cases, we still need low-level APIs to support us to reach some goals.
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.
we can transform async generators into coroutines (async functions) by creating a new async function that simply starts iterating over the async generators, so every name is overloaded which makes communication kinda hard. I will just assume the happy case of @coroutine getting a downgrade. Don't use it anyway.
Yeah! I know that @coroutine and yield from are deprecated. This article focuses on how coroutines cooperate with event loops in Python. You remind me that I should add a warning to inform your information. Thanks.
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.
async/await is a better design pattern without considering low-level APIs such as epoll. It is not a new kind of threading/loop. Python provides a user-level scheduler for developers, so they don't need to implement their scheduler from scratch. In my opinion, the reason why using an event loop can acquire better performance is to decrease the number of times to lock some critical sections. Also, this pattern can increase the cache hit and mitigate CPU context switch frequency.
reply