I'm not sure why this wasn't done before.
- Removes typedef of pthread_t on Windows, which fixes a native compile issue on mingw (@diapolo :-)
I'm not sure why this wasn't done before.
Good stuff. One nit: if we are touching this code, rename our CreateThread() to something not found in Windows or Linux standard libraries.
Yes, good point. Any suggestions? StartThread? SpawnThread?
You are my hero :-D, what about just NewThread()? Well your ideas are also fine and I'm pro rename.
1298 | @@ -1299,3 +1299,15 @@ void RenameThread(const char* name) 1299 | (void)name; 1300 | #endif 1301 | } 1302 | + 1303 | +bool CreateThread(void(*pfn)(void*), void* parg) 1304 | +{ 1305 | + try 1306 | + { 1307 | + boost::thread(pfn, parg); // thread detaches when out of scope
So all our threads are closed, even when for example we crash (thread unrelated)?
How do you mean that? We don't currently have any functionality to "catch" crashes (something like google breakpad could help there, but there's the not-so-small issue of accidentally sending private key data), I'm not sure how it's related to created threads.
I refered to your comment here and just wanted to know if it includes a clean shutdown of threads started via CreateThread(), if the client crashes and if the crash is unrelated to the function here itself.
I'll let others choose the color of the bike shed ;p Just want to avoid clashing with existing symbols. It certainly caused confusion in the past.
Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/bd6db5608cd4e6a2ee77d6e409c8c3488d028cce for binaries and test log.
I tried that patch with my local build, no compilation problems and the resulting exe starts just fine.
I'm not sure why this wasn't done before.
- Removes typedef of pthread_t on Windows, which fixes a native compile issue on mingw.
Prevent clash with win32 API symbol
Rebased and renamed the function to NewThread
ACK
ACK