Hacker News Reader

Comment by carllerche | Hacker News Reader

The expectation is that all code running on the Tokio scheduler does not block and does not do anything CPU intensive.

There is follow up work planned to allow annotating blocking / CPU intensive bits of code so that the scheduler can do something smarter (things like you linked).

The old scheduler already had such an annotation, but in the interest of shipping, this has punted in the new scheduler.

View on HN

Is that expectation wrt. responsiveness guarantees? In other words, if I'm just interested in throughput are CPU intensive tasks a problem? For example, my expectation is that it would be appropriate to use the new Tokio scheduler to parallelize a compute intensive simulation workload (where inside a "frame" responsiveness is not a problem).

The Tokio scheduler uses cooperative multitasking (non-preemptive). So, if your task runs without yielding it can prevent other runnable tasks from executing.

So, if that is acceptable, then it is fine.

Is there a recommended approach to dealing with the occassional cpu intensive task?

Supposing you were running an http server and most responses were very quick - but occassionally a request came along that required calculating pi to the n billionth digit.. (for example).. Would you need to farm that request to a separate process - or could you keep it in process but in a separate thread outside of Tokio?

I believe tokio-threadpool is designes for this scebario.

Right now, CPU intensive code blocks or code blocks that block need to be annotated. This way, the scheduler can respond accordingly (cooperative).

Reply on news.ycombinator.com