6 Commits (0f3e9fa56504f2ea2fa114fd52d41d9f5a5b6d75)

Author	SHA1	Message	Date
George Joseph	170b206925	channelstorage: Allow storage driver read locking to be skipped. ... After PR #1498 added read locking to channelstorage_cpp_map_name_id, if ARI channels/externalMedia was called with a custom channel id AND the cpp_map_name_id channel storage backend is in use, a deadlock can occur when hanging up the channel. It's actually triggered in channel.c:__ast_channel_alloc_ap() when it gets a write lock on the channelstorage driver then subsequently does a lookup for channel uniqueid which now does a read lock. This is an invalid operation and causes the lock state to get "bad". When the channels try to hang up, a write lock is attempted again which hangs and causes the deadlock. Now instead of the cpp_map_name_id channelstorage driver "get" APIs automatically performing a read lock, they take a "lock" parameter which allows a caller who already has a write lock to indicate that the "get" API must not attempt its own lock. This prevents the state from getting mesed up. The ao2_legacy driver uses the ao2 container's recursive mutex so doesn't have this issue but since it also implements the common channelstorage API, it needed its "get" implementations updated to take the lock parameter. They just don't use it. Resolves: #1578	4 months ago
George Joseph	5002f9b7bd	channelstorage_cpp_map_name_id: Add read locking around retrievals. ... When we retrieve a channel from a C++ map, we actually get back a wrapper object that points to the channel then right after we retrieve it, we bump its reference count. There's a tiny chance however that between those two statements a delete and/or unref might happen which would cause the wrapper object or the channel itself to become invalid resulting in a SEGV. To avoid this we now perform a read lock on the driver around those statements. Resolves: #1491	4 months ago
George Joseph	377d20f50c	channelstorage_cpp_map_name_id.cc: Refactor iterators for thread-safety. ... The fact that deleting an object from a map invalidates any iterator that happens to currently point to that object was overlooked in the initial implementation. Unfortunately, there's no way to detect that an iterator has been invalidated so the result was an occasional SEGV triggered by modules like app_chanspy that opens an iterator and can keep it open for a long period of time. The new implementation doesn't keep the underlying C++ iterator open across calls to ast_channel_iterator_next() and uses a read lock on the map to ensure that, even for the few microseconds we use the iterator, another thread can't delete a channel from under it. Even with this change, the iterators are still WAY faster than the ao2_legacy storage driver. Full details about the new implementation are located in the comments for iterator_next() in channelstorage_cpp_map_name_id.cc. Resolves: #1309 (cherry picked from commit 830dd4656c)	5 months ago
George Joseph	ca7db896e5	channelstorage: Rename callbacks that conflict with DEBUG_FD_LEAKS. ... DEBUG_FD_LEAKS replaces calls to "open" and "close" with functions that keep track of file descriptors, even when those calls are actually callbacks defined in structures like ast_channelstorage_instance->open and don't touch file descriptors. This causes compilation failures. Those callbacks have been renamed to "open_instance" and "close_instance" respectively. Resolves: #1287	5 months ago
George Joseph	abdfb5aa87	channelstorage_cpp_map_name_id: Fix callback returning non-matching channels. ... When the callback() API was invoked but no channel passed the test, callback would return the last channel tested instead of NULL. It now correctly returns NULL when no channel matches. Resolves: #1288	5 months ago
George Joseph	e7d990b66b	Alternate Channel Storage Backends ... Full details: http://s.asterisk.net/dc679ec3 The previous proof-of-concept showed that the cpp_map_name_id alternate storage backed performed better than all the others so this final PR adds only that option. You still need to enable it in menuselect under the "Alternate Channel Storage Backends" category. To select which one is used at runtime, set the "channel_storage_backend" option in asterisk.conf to one of the values described in asterisk.conf.sample. The default remains "ao2_legacy". UpgradeNote: With this release, you can now select an alternate channel storage backend based on C++ Maps. Using the new backend may increase performance and reduce the chances of deadlocks on heavily loaded systems. For more information, see http://s.asterisk.net/dc679ec3	5 months ago