This was a regression in 0bb81a43c9e4fffb37cc2234c1b0fbae42020ceb which was not keeping an edge case in mind if a weak pointer is locked during object destruction. This issue was fixed by 525a05ea2b1d00a1db901f883f1755943aeff33c, but that is not enough since it causes CharacterJointEffect::get_character() to return null now, so we need a separate method to check if a CharacterJointEffect belongs to a given character. This is more efficient, too.
Fixes#330
This came up in #330; the Character destructor caused something to call lock() on a weak pointer to that character, which would induce a ref() and unref() pair, but since the refcount was 0, this would call the destructor and thereby create infinite recursion.
I considered instead calling mark_deleted() inside unref() so that the callbacks get to run before the object is actually deleted, and was_deleted() will become true as soon as unref() reaches 0. However, this would require grabbing the lock in unref() to be fully thread-safe, since we would need to bring the refcount to 0 and mark the object as deleted in one atomic operation, so this would be an unacceptable general performance penalty.
Instead, WeakPointerTo::lock() now atomically increments the reference count if it is not already zero, and returns null otherwise. This should be safe because the object cannot be deleted while the WeakReferenceList lock is held.
This lets one drop the reference to AICharacter after adding it to a flock or AIWorld without crashes.
Also replace the silly and inefficient custom-rolled linked list implementation of AICharPool with a vector, and add additional safety checks.
Fixes#318
This makes it possible to include it multiple times in a single
translation unit, and/or multiple times in a single dynamic
library (and without excess code bloat, too).
Newer versions of FFmpeg deprecate returning 0 to indicate
EOF, and instead request use of AVERROR_EOF.
The oldest supported versions of FFmpeg/libav will treat any
error code the same as returning 0.
Fixes#315
This comes up when building with DEBUG_THREADS; there is a PipelineCycler created at static init time, and the type tracking in Pipeline won't work properly if the CData's parent's TypeHandle has not yet been initialized.
There is a bug in clang versions before 3.2 (including the one shipped with Xcode) that makes it give a "conflicting types" compile error when there is a static constexpr function defined outside the class. The way to work around this is either to remove one of the "static" or "constexpr" keywords, or to simply put the definition inline.
See: https://stackoverflow.com/a/17494592/2135754
I would try and upgrade Xcode to version 5 to see if the problem is fixed, but the buildbot still runs OS X Lion (10.7) and the last version of Xcode that works on Lion is 4.6.3, so it seems easier to just apply these workarounds for now.
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.
To access a WeakPointerTo in a thread-safe way, use something like this:
if (auto ptr = weak_ptr.lock()) {
..use ptr as regular PointerTo
}
The new implementation no longer needs a reference to be stored to all weak pointers on the WeakReferenceList; a mere count of weak pointers is sufficient. Therefore, callbacks theoretically no longer require a WeakPointerTo to be constructed.
The WeakPointerTo class is not actually atomic; it could be made so, but I don't believe it's worth it at this time.
This allows using a coroutine to build up a more complex sequence including transitions (eg. scripted cutscene), as well as provide a standard way to register callbacks upon completion of the transition.
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
