On 6/03/2020 22:47, Adham Sabry wrote:
where can i find the duration of sleep that basic_thread_pool does then wakes up???it sleeps till some methods like submit are called.i thought submit just make tasks without starting the thread and async is the one which launch thread but i was totally wrong drived by asio paradigm what is the reason of wake up??is it timed internally or it needs explicit launching?we can do both using schedulers although i do not know how also why async leads to pausing test_executor_adaptor???here async return is assigned to variable t2 so it will not block in async destructor,but will work asynchronously till the scope is ended and then block in destructor of async???this i do not know answer to it????why async pause ??? what do you mean by sleeping?you meant to sleep between submit calls so they are finished
There is no specific time. The threadpool threads are asleep waiting for work to be submitted. As soon as you actually submit work (whether directly via submit() or indirectly via async()), the thread is eligible to wake up (in fact it might wake up and complete the work before submit even returns) -- that part is entirely up to your OS's thread scheduler. If it helps: async() is essentially internally just a call to submit() with some additional wrapping to give you a future representing the completion of the operation. [This is not precisely accurate but it's a good way to think about it for understanding purposes.] My point about the async calls is that because you're calling async and then future.get(), you're blocking the original thread waiting for something else, which allows the threadpool work to complete in the background, regardless of which threadpool the work was submitted to. If you completely removed the future.get() calls (even if you still called async), then you might end up destroying the threadpool before it actually did the work, thus it would appear that submit() did nothing. (And the asyncs would also end up doing nothing.) But because like I said this is up to your OS's thread scheduler, it might sometimes make some progress on some of the work before actually being destroyed, which can be confusing. If you have a sleep (or any other work running long enough) in there, so that you don't destroy the threadpool too soon, then it will complete in the background. Usually you need to structure your code in a way that assures that the things you want to complete have actually completed before you destroy them. Waiting on futures is an easy way to do that in a toy example, but it can get more complex in a real application. (I personally consider futures almost entirely useless in a real application -- but that doesn't make learning about them useless.) I'd recommend finding a good book on the topic to read. (Though books specifically on executors are probably rare, as it's relatively new ground.) Threading and async in C++ can be very hard to get correct unless you have the fundamentals down strongly.