Codechange: Use C++11 functions for threading #7379
Conversation
|
I would suggest we remove DOS support for now, giving this PR priority. DOS has more issues (very slow), lacks networking, and more of that. Removing it has more benefits, but this shows how much we benefit from removing targets that are rarely used, and don't really support modern solutions. Just my 2 cents! |
michicc
force-pushed
the
pr/c++11-thread
branch
4 times, most recently
from
4daf03a to
f7177bc
Compare
michicc
force-pushed
the
pr/c++11-thread
branch
2 times, most recently
from
9341231 to
21e6d4e
Compare
| * Check if we can use a thread for modal progress. | ||
| * @return Threading usable? | ||
| */ | ||
| static inline bool UseThreadedModelProgress() |
There was a problem hiding this comment.
I wonder how useful this is, given not everywhere else checks for usable threads? (I only see this used for newgrf scan & worldgen) Should probably be all or nothing, and abort if the threads fail
There was a problem hiding this comment.
Constructing a mutex must succeed, locking a mutex may fail. The mutexes for model progress are locked right in main, if that fails it's instant exit. For the real existing C++11 implementations, mutex lock fail will only occur if threading at all is unusable.
The other threading sites try to create their threads first and fall back to a non-threaded implementation. We never got any bug reports that creating a thread succeeded whilst the subsequent mutex lock failed, and I don't see any reason that would change with this PR.
michicc
force-pushed
the
pr/c++11-thread
branch
2 times, most recently
from
0301d8b to
f963e42
Compare
|
I don't see any reason why this PR should touch #6857. Internally, it all resolves down to pthreads anyway as before. |
I did once get networking working on DOS via WATTCP, but that was a long time ago, and I never bothered trying to get that into OpenTTD itself. (In fact, I think it may have predated Rubidium's official DOS port.) No objections to dropping it, and you never know, perhaps one day somebody will 'port' std::thread to DJGPP! |
michicc
force-pushed
the
pr/c++11-thread
branch
from
f963e42 to
cb384ef
Compare
michicc
force-pushed
the
pr/c++11-thread
branch
from
cb384ef to
bb3c386
Compare
|
This looked fine when I read through it a few days ago, are any more changes incoming or is it ready for review? |
|
There were (and are) no changes except the comment aligning and rebasing. |
A conforming compiler with a valid <mutex>-header is expected. Most parts of the code assume that locking a mutex will never fail unexpectedly, which is generally true on all common platforms that don't just pretend to be C++11. The use of condition variables in driver code is checked.
We assume a conforming C++11 compiler environment that has a valid <thread>-header. Failure to run a real thread is handled gracefully.
The C++11 STL has functions for threading and synchronization, which means we can retire our homegrown platform-dependent code.
This PR assume a conforming C++11 compiler with conforming header files. DJGPP in it's current incarnation ships
threadandmutexheaders, but does not define the required types (not even as empty dummies). As such, this PR kills DOS unless a lot of #ifdef's are added.We do not assume that starting a thread will succeeded, but do assume that if threads work, mutexes do work as well.