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.
This introduces AsyncFuture as a new base class of AsyncTask. It's modelled after asyncio's Future class, except that it is thread-safe and you can use result() to block the current thread waiting for the future to finish (of course this is not necessary for use with coroutines).
AsyncFuture should be used for any operation that finishes in the future, to get the benefit of awaitability within coroutines as well as a standard interface for querying status and results of the operation as well as cancelling it. As such, it's been implemented in various places, including texture.prepare() and win.trigger_copy().
Note that AsyncFuture is intended to be used *once*; it cannot be used more than once. As an example of how this works, tex.prepare() will return the same future as long as the prepare isn't complete, but when it is done, subsequent calls to tex.prepare() will return a new future.
* Better support for typedefs
* Same code should compile for both 32-bit and 64-bit
* C++11 typed enum support
* Synthesize __setitem__ when operator [] returns reference
* Rewrite coerce system to have better performance
* Change semantics of __getattr__ and __setattr__ to match
Python's, add __getattribute__, __delattr__ and __delitem__
* Improve performance of slot functions a bit more
* Reduce memory overhead of type system
* Some support for wrapping arrays of numeric types
* C++11 character type support in cppparser
* Chars are handled as strings of length 1
* Template functions for CreatePyInstance that use runtime type map
* More functions from dtool as extension functions
* Code cleanup
cxx: Fix missing includes masked by composite builds.
misc: Fix typos in comments.
config: Fix missing config forward-declarations.
direct: Adjust Python imports to panda3d.* instead of pandac.*.
display: Split graphicsWindow out into an extension.
framework: Use if/elif/elif/endif instead of ifdef/elif/elif/endif.
ode: Remove erroneous INLINE declarations.
interval: Fix missing import.
Sam Edwards
rdb
Younguk Kim
tobspr