🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/139886

• 📄 Preview Python docs built from this PR
• 📄 Preview C++ docs built from this PR
• ❓ Need help or want to give feedback on the CI? Visit the bot commands wiki

Note: Links to docs will display an error until the docs builds have been completed.

This comment was automatically generated by Dr. CI and updates every 15 minutes.

Thanks @cyyever .
Do you mean that when fut is destroyed in that scope, it will wait for the lambda it wraps to finish anyway?
If so I agree that std::async may not be effective here.
Cc @fduwjj

Yep, the blocking behavior of std::future destructor is confirmed (tho as the thread below mentioned, controversial).
https://stackoverflow.com/questions/23455104/why-is-the-destructor-of-a-future-returned-from-stdasync-blocking

@fduwjj If it is intended for the dumpDebuggingInfo call to be non-blocking to the heartbeat monitor thread, do you want to add a waitForFutureOrTimeout call after creating that std::async? Just like you did in the lines below. Thanks!

Yep, the blocking behavior of std::future destructor is confirmed (tho as the thread below mentioned, controversial). https://stackoverflow.com/questions/23455104/why-is-the-destructor-of-a-future-returned-from-stdasync-blocking

@fduwjj If it is intended for the dumpDebuggingInfo call to be non-blocking to the heartbeat monitor thread, do you want to add a waitForFutureOrTimeout call after creating that std::async? Just like you did in the lines below. Thanks!

@kwen2501, waitForFutureOrTimeout, as the name suggests, also waits after creating the std::async.

You are right, I thought waitForFutureOrTimeout have some abort mechanism (it does), but here we may not want to fire the abort because it is best effort.