Closed yinchunxiang closed 8 years ago
In the long gone past this was actually how the first version worked. It changes the behaviour though. Back then I got lots of emails about how the pool wouldn't "finish his work" if it was destroyed. That can be sensible behaviour but probably shouldn't be the default. Without the emptiness check there could be enqueued tasks that get never executed... (and as a result futures that would just block indefinitely if waited on).
what about using a thread for "closing the pool finally once it is destroyed" ?
Got it, thanks :)
Can we just return when this->stop is true