Set editoast tokio flavor multi-thread

[flomonster]

• Bump to rustc 1.79.0
• Use tokio multi thread scheduler instead of current thread.

Tokio doc: https://docs.rs/tokio/latest/tokio/attr.main.html#multi-threaded-runtime

Note

When printing the flavor in the main we have MultiThread instead of CurrentThread.
However we still observe CurrentThread when printing inside an endpoint.

[ElysaSrc]

That sounds like an incredibly simple yet perfect solution

[flomonster]

That sounds like an incredibly simple yet perfect solution

This does not fix the usage of join_all futures.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 28.45%. Comparing base (d6f255b) to head (30d3cbc).
Report is 4 commits behind head on dev.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@             Coverage Diff              @@
##                dev    #7924      +/-   ##
============================================
- Coverage     28.48%   28.45%   -0.04%     
  Complexity     2059     2059              
============================================
  Files          1254     1256       +2     
  Lines        154469   154592     +123     
  Branches       3047     3049       +2     
============================================
- Hits          44007    43993      -14     
- Misses       108647   108782     +135     
- Partials       1815     1817       +2     

Flag	Coverage Δ
core	75.00% <ø> (ø)
editoast	71.60% <ø> (-0.07%)	⬇️
front	9.96% <ø> (-0.02%)	⬇️
gateway	2.34% <ø> (ø)
railjson_generator	87.49% <ø> (ø)
tests	72.93% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[woshilapin]

Digging a bit into actix-web, it seems to basically launch as many actix worker as there is CPU available by default. An actix worker is basically an OS thread with a mono-thread tokio runtime in it. Here is how it works.

1. We set up the number of actix worker in editoast
2. This number of worker is stored into threads of the ServerBuilder into our instance of HTTPServer
3. This threads number is used to instantiate as many ServerWorker
4. In the ServerWorker::start, the handle on the current tokio::Runtime is gathered
5. Always in ServerWorker::start, a new OS thread is spawned (remember, ServerWorker::start is called as many times as there is workers)
6. Finally, inside this new OS thread, a new mono-threaded tokio runtime is launched

Note that a lot is happening in ServerWorker::start which I'm not entirely sure the impact. But basically, it probably doesn't matter if our fn main is multi-threaded or not since actix is basically running a mono-threaded tokio runtime in independent OS threads from what I understand.

That said, I believe that defaulting to a multi-threaded tokio runtime is good anyway, even if it might not help us in what we're looking for.

[ElysaSrc]

That sounds like an incredibly simple yet perfect solution

This does not fix the usage of join_all futures.

My bad, I thought it would.