crazyguitar

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!

Thanks. This is a awesome suggestion. Will dive deep what is the better way to do.

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 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.

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.

Oh! sorry! thx

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.

Oh! I understand. You're right. Some descriptions mix coroutines and event loops together. thx

Nice. Thanks

Awesome! Thank you

I understand. I will review my contents persistently. BTW, if you are available, could you give me some writing tips? Thank you so much.

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.

I agree.