Summary:
Fix a race condition when we create a thread and immediately destroy
This case should be supported.
What happens is that the thread function needs the Data instance
to actually run but has no shared ownership and must rely on the
WindowsThread instance to continue existing.
To address this we change unique_ptr to shared_ptr and then
acquire an additional refcount for the threadproc which destroys it
just before the thread exit.
We choose to allocate shared_ptr instance on the heap as this allows
the original thread to continue w/o waiting for the new thread to start
running.
Closes https://github.com/facebook/rocksdb/pull/3240
Differential Revision: D6511324
Pulled By: yiwu-arbug
fbshipit-source-id: 4633ff7996daf4d287a9fe34f60c1dd28cf4ff36
Summary:
introduce new methods into a public threadpool interface,
- allow submission of std::functions as they allow greater flexibility.
- add Joining methods to the implementation to join scheduled and submitted jobs with
an option to cancel jobs that did not start executing.
- Remove ugly `#ifdefs` between pthread and std implementation, make it uniform.
- introduce pimpl for a drop in replacement of the implementation
- Introduce rocksdb::port::Thread typedef which is a replacement for std::thread. On Posix Thread defaults as before std::thread.
- Implement WindowsThread that allocates memory in a more controllable manner than windows std::thread with a replaceable implementation.
- should be no functionality changes.
Closes https://github.com/facebook/rocksdb/pull/1823
Differential Revision: D4492902
Pulled By: siying
fbshipit-source-id: c74cb11
Dmitri Smirnov