Does the reactor only support fallback way?
kingluo opened this issue · comments
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.
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.
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?
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.