The intended purpose of this function is to restore an exception
that has already been raised and saved with PyErr_Fetch. It should
not be used to raise new exceptions nor should it be used to clear
the current exception.
The especially egregious example is
`PyErr_Restore(exc_type, nullptr, nullptr);`
as the null value may not be handled correctly.
A task returning DS_interrupt would only interrupt the current task chain, not the entire task manager. This meant that other tasks might get run with an exception state set, causing the exception state to get stomped on or the Python interpreter to complain.
Fixes#692
See #550. Now that we use the Vista API for condition variables, the only place where the distinction is still relevant is Windows XP, and it's just not worth it for that one corner case.
* In C++ reference, only pick up classes defined in .h file
* Add a few excludes to C++ reference that aren't public API
* On class index pages, reduce number of columns
* Add @since for some methods/classes that are new in 1.10.0
* Fix/improve a few docstrings here and there
Even a brief error message in the assertion is infinitely more useful to a user who is not at home in the source code, especially for assertions that may reasonably be triggered by honest user mistakes.
This renames acquire/release to lock/unlock in order to be compatible with std::lock_guard and std::unique_lock (which will eventually replace the *MutexHolder classes). It will also allow us to typedef MutexImpl to std::mutex later on.
We don't guarantee a specific order in this case, especially because they can be run in either order if there is more than one thread, but it is still useful to have a defined order for single-threaded task chains. To that end, tasks
are now run in the order in which they were added to taskMgr.add (in absence of any other ordering constraints).
Fixes#309
This is designed to sanity-check the buildsystem, ensuring that the
expected BUILDING_ macros are defined at the expected time. It
also helps catch cases where the wrong BUILDING_/EXPCL_ macros
are used.
The GCC documentation states that, as of GCC 2.7.2, these aren't
necessary for proper program behavior. The documentation further
discourages their use because they don't suppress unnecessary code
duplication.
The Panda codebase these days uses "extern template class" instead,
which tells the compiler not to perform implicit template expansion
because an explicit template expansion is available for linking
elsewhere in the program. This is a more compiler-neutral way of
achieving the same thing as '#pragma interface', making
'#pragma interface' not only redundant, it could also mask problems
in the "extern template class" machinery.
Sam Edwards
rdb
Younguk Kim