[REQ] Explain destructor behavior for thread_pool

[MakotoE]

Describe the new feature
In the README.md, explain what would happen when the destructor of thread_pool is called.

Code example
N/A

Additional information

I see that ~thread_pool() will wait for all tasks to finish, then destroys all threads. It might be nice to state this in README.md, in the library reference section. I didn't find any mention of this. I think it is important to know.

[bshoshany]

Hi @MakotoE and thanks for opening this issue! The reason that the destructor is not mentioned in README.md is that the user is not supposed to call the destructor manually, so it is not part of the public API, but an internal implementation detail. Is there any specific reason that the destructor should be mentioned in README.md?

[MakotoE]

Ok, the part about the visibility of the destructor makes sense. In my case, I was wondering if my app would close without delay, as tasks may be queued up in the thread pool. After seeing that the thread pool destructor may block to wait for the tasks, I decided that I should first purge the pool before destroying the pool.

The destructor may be hidden in the sense that a user should not call ~thread_pool() directly, but I feel like people will be worried about the destructor behavior for a thread pool when it loses scope. Maybe it's just me, I don't know. I'll just leave my opinion here, and we can see if other people think the same or not. No other issue in the past has talked about it.

[bshoshany]

Thanks for the suggestion! I will include a description of the destructor behavior of the thread pool in the documentation for the next release.

[bshoshany]

Update: This is now implemented in v4.1.0.