There is a minor chance that console or init thread would access already freed memory when core is shutting down and cleaning up state. To avoid any danger of having random bugs caused by the potential data race I decided to make sure the shutdown code waits for the thread to exit first. Windows change is completely untested. It is purely based on msdn documentation. |
||
---|---|---|
CMake | ||
build | ||
depends | ||
dfhack-config | ||
docs | ||
library | ||
package | ||
plugins | ||
reversing | ||
scripts@56a209a9b4 | ||
test | ||
travis | ||
.gitignore | ||
.gitmodules | ||
.travis.yml | ||
.ycm_extra_conf.py | ||
CMakeLists.txt | ||
Contributing.rst | ||
LICENSE.rst | ||
README.html | ||
README.md | ||
conf.py | ||
dfhack.init-example | ||
index.rst | ||
onLoad.init-example |
README.md
DFHack Readme
DFHack is a Dwarf Fortress memory access library, distributed with scripts and plugins implementing a wide variety of useful functions and tools.
The full documentation is available online here,
from the README.html page in the DFHack distribution, or as raw text in the ./docs
folder.
If you're an end-user, modder, or interested in contributing to DFHack -
go read those docs.
If that's unclear or you need more help, try the Bay12 forums thread or the #dfhack IRC channel on freenode.