What are the coroutines?

Question

What I’ve been given to understand is that it’s a new way of writing asynchronous code, allowing you to avoid blocking the thread.

This leads me to assume that they are an alternative to class Thread of Java (and/or others based on it).

So I’d like to know:

• What they are and how they work.
• Advantages and disadvantages compared to the threads.

Answer 1

Are routines cooperatives, that is, are routines (functions, methods, procedures) that agree to stop its execution allowing another routine to be executed at that time hoping that this secondary routine will return the execution to it at some point, so one cooperates with the other.

This allows execution in parts. One of the great benefits is to maintain some state between execution times, so its main function is to facilitate segmented execution, possibly creating some abstraction in execution.

The main mechanism in languages to achieve this is the yield. You can also use a state machine manually or by library.

So they maintain the state of their routine somewhere, including where they stopped to be able to continue from there when they return.

From this structure it is possible to create a specific state machine to allow execution to create execution asynchronicity that can replace threads which were used to allow parallel and concurrent execution, but was the wrong mechanism in these cases.

It’s not that threads are not useful, they are, but only one for each processor, thus allowing multiple executions to occur effectively simultaneously. But the execution of the various competing operations not necessarily simultaneous, do not benefit from them. Each processor can only run one thing at a time, even if it has the illusion of running several. It is more advantageous to let routines tell you when they no longer need to run than to let the operating system keep changing this often without need.

Then a routine performs its part and in the moments it will make IO it can deliver the execution to another routine. IO will be done by the operating system or by the service that is being used on its own, it has nothing to do with your application, so there is no reason why your application is waiting without doing anything. With the corrosion she cooperates saying that another routine can be performed at this time. When the IO part is finished back to the previous routine finishing with the IO result at hand.

There is not so much difference, only that the execution suspension is determined by the routine itself and not by the operating system, so it is called cooperative, the operating system makes way preemptive.

Some languages abstract all this, others require you to take care of the entire execution exchange mechanism (the state machine), which in practice makes "nobody" use.

Thread is useful when you need to create processing lines and the biggest advantage is when you have multiple processors available. Of course the thread, which is an operating system resource, can be used as execution state machine, but has a higher cost. See more. Corrotinas in this context is most useful when it has input and output or when it needs processing lines that go beyond the available processors.

There is a lot of waste in the use of thread because it has the cost of managing the operating system, it has the context exchange that is expensive, it has the high probability of a thread be triggered and have nothing to do. Corrotinas are very light, easily managed by the application itself and are driven as needed. "on-demand" is the secret here.

Of course, if the routine you’re supposed to cooperate is misspelled, you might be stalling for a long time, screwing things up. Preemption forces the change of execution of a routine thread to another, even if the app doesn’t help.

There was a performance revolution on HTTP servers, which Node took to fame without having the merit, precisely by using corrotinas instead of threads.

To corrosion is orthogonal to thread, then one does not depend on the other, but it may be that a corrosion is placed on thread separate, depending on the need.

In the comments the AP talks about writing sequential code that ends up being distributed concurrently, and that’s right, provided the language or even the library helps.

For lack of a better mechanism in the years 90 the use of threads for something that didn’t need them, including because almost no computer had more than a processor.

Better understand the difference between parallel and simultaneous.

The await of C# does just this. Kotlin has very similar mechanism.

Python example:

Wikipedia.

Has a reply in the OS with more details.