[dfox]

There is one significant difference: Windows did context-switches in the blocking calls and did not rely on the program code having "the right structure" needed for straight co-routines to work.

The difference between preemptive and cooperative multitasking is not whether you do full context switches, but whether there is a way to do context switch at a point where the process does not expect it (ie. by handling some kind of timer interrupt as scheduling opportunity).

[amelius]

Does Rust allow a computational for-loop to be interrupted somehow?

Computation can also be viewed as a blocking operation.

[steveklabnik]

The only yield points are .await points. If there's an .await in a loop, then sure, but otherwise no.

[amelius]

What is the cost of an .await point?

For this to work, perhaps Rust should cooperate too, inserting .await points at strategic places in the code, to keep cost low but still guaranteeing a certain responsiveness of the overall system.

[jfkebwjsbx]

That would explode the state machine size and make its performance characterization very hard.

And you would need to avoid having any kind of call to external code (or yield before and after every such call, and pray for the best).

[mwcampbell]

If I understand the futures::pending!() macro correctly, one can use that to add a forced yield point in a loop, right?

[steveklabnik]

Yes, it creates a future, and then immediately .awaits it.

[dfox]

That is interesting point that I originally wanted to mention. There are systems that take the middle ground approach of using something that the program has to eventually execute if it is running indefinitely as scheduling opportunity. Typically an backward jump or something that allows you to do backward jump (ie. function call), this is the case for erlang, SOAR (which was recently mentioned on HN) and interestingly enough Ericsson AXE, which is to large extent erlang-like VM implemented in hardware (which predates erlang).