Hello. > Larry's "sync" marker would be a change to *run-time behaviour*: when > myFun() begins, the scheduler switches into "linear mode", until the end > of that function. In that mode, when a suspend() point is reached, the > scheduler immediately resumes that coroutine rather than choosing a > different one.
This is very similar to the async\protect mechanism, but with a restriction that forbids switching inside IO functions. It is possible to implement this, but other coroutines will experience serious starvation. In other words, it can be done, but it should not be done. Concurrency works well when the programmer follows one rule. Every coroutine must have many suspension points, and the time between these points must not exceed a certain value. This is a typical scenario for web applications. It is not universal. There are completely different scenarios. For example, a PHP linter. For a PHP linter, parallel execution will be more useful. Async functions can also help when combined with threads. The architecture will be as follows. * A job manager that monitors execution where one coroutine is one task. * A pool of threads where there are almost no coroutines. The job manager creates a coroutine that sends a task to a separate thread and handles it. It can also perform IO. In the separate thread, coroutines are not really needed because the code mostly performs heavy computations. Of course, TrueAsync will provide the programmer with a channel for interacting with a coroutine in another thread, and that interaction will also be asynchronous. This approach is 100 percent memory-safe because it fully controls which object is passed through the channel. In other words, by understanding the strong side of coroutines and having tools like a thread pool, a programmer can build PHP applications without true parallelism that will not be inferior to Go. The only downside is that you have to manually split the code into an IO stream and a job worker. This adds a bit of development time, but not critically. --- Best regards, Ed
