What's the best way to use async main?

[AsenHu]

I read #6831 and learned this:

1. Try not to run code in an async main fn (or block_on), because code there cannot be work-stealing and will run slower.
2. The thread that calls block_on (that is, the thread that runs async main fn) will not join the thread pool to process tasks.

This leads me to a very strange conclusion:

In async main fn, simply include a spawn to run a manage task in the thread pool (such as listening on TCP and starting new tasks), then block the main thread until the task is complete.

I don't think this is correct, because the main thread doesn't do anything. I think I'm misunderstanding something. In general, I want to know what we should do in the main function.

[ADD-SP]

Try not to run code in an async main fn (or block_on), because code there cannot be work-stealing and will run slower.

Actually, the work-stealing or not doesn't matter for this topic as block_on always blocks the current thread. Work-stealing is an optimization which targets to worker thread. For example, there is an async task does AI reasoning running on a worker thread, this prevents the worker thread from executing async tasks in the local task queue. Work-stealing allow another idle worker threads steal tasks from other worker threads. However, thread who runs the block_on doesn't have the local task queue, so work stealing doesnt matter.

For multi thread runtime, since the thread who runs block_on is not a worker thread, and only worker threads can poll the underlying I/O event, timers, etc, majority of async notifications to the block_on thread has to cross the thread boundary. This is the reason that it is recommended to let the listener into a tokio::spawn.

[AsenHu]

Thanks for your reply. It seems that in network programming, the main thread is best left idle from the beginning until the end.

I have another question: why not have the main thread also do some work, like joining a worker thread pool or handling IO events or timers?

Are there any benefits to leaving the main thread idle? Or are there any design considerations?

[ADD-SP]

why not have the main thread also do some work, like joining a worker thread pool or handling IO events or timers?

Technically, we can make the thread who called block_on acts like a worker thread, and handle the block_on future specially (block_on doesn't require the Future is Send).

Since this adds complexities to the codebase, and the solution is pretty simple (already been documented), the motivation to improve it is not significant.

But anyway, we always welcome PRs to improve this part.

[AsenHu]

I see, thanks for your reply!