Does the reactor only support fallback way?

[kingluo]

First access of CURRENT_REACTOR would run a reactor in a background thread? Does it mean for threadpoll executor, each thread local reactor would be running in a paired background thread? Why not run the reactor via unpark() just like tokio (the runtime setup would init the reactor directly).

Why exists so-called fallback way? Please help to clarify it.

[yoshuawuyts]

Does it mean for threadpoll executor, each thread local reactor would be running in a paired background thread?

Could you expand on this? I'm not sure I follow.

To my understanding we run a single reactor for the whole program, rather than a reactor-per-thread. This has some tradeoffs, but for us the benefit was simpler code that's easier to maintain and seems to perform about as well as the reactor-per-core design.

[kingluo]

Yes, my misunderstanding. I check the codes again, and found the reactor is singleton instance via HANDLE_FALLBACK atomic.

and seems to perform about as well as the reactor-per-core design.

The threading sync stuffs cost nothing?

[yoshuawuyts]

The threading sync stuffs cost nothing?

Everything has tradeoffs. When combined with work stealing, the reactor-per-core design needs to hold references to the original reactor when performing work on a separate thread. This is very difficult to get right, and the potential performance gains didn't seem worth it.