I guess we would have to "color" all rayon code as async for that, and then it would basically be tokio's threaded runtime -- so go use that if it works for you. 
This doesn't sound right. When it sleeps the thread, it will block other tasks from progressing. Why not yield to the executor so that it can switch to another task?
This issue is made even worse in single threaded executors.
1 Like
Hm. I am not sure yielding to the executor is preferable. I suspect it will increase latency. And performance implication are not clear.
Essentially this boils down to whether using std::sync::Mutex<T> in async code is wrong/bad. If all critical sections are short-lived, sync mutex might be better than async one in terms of both latency and performance (but it is hard to tell without benchmarks).
Please note, that it does not use sleep to wait for recieved value/send slot. It can only ever sleep when acquiring the mutex, thus this will only happen if many native threads are trying to use the channel simultaneously.
I am not sure I understand why.
Anyway, the point is there is a noticeable amount of code that sleeps inside poll. So if we are going to accept this proposal, we will need a better migration policy.
P.S. not an author of the lib; just got curious about its performance for a recent reddit thread.
Ignore this - I failed to read further down the thread, in replies to others.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.