diff options
author | Tzafrir Cohen <tzafrir.cohen@xorcom.com> | 2014-06-23 07:44:19 +0000 |
---|---|---|
committer | Tzafrir Cohen <tzafrir.cohen@xorcom.com> | 2014-06-23 07:44:19 +0000 |
commit | 3451d6a72d0499a83d82ce03d00d2156a1258c8b (patch) | |
tree | 6b3bf6bf6b1c5c5b840d1083cdc92c86f508f1ed /configure.ac | |
parent | 682357dced7caccaa7e11164bf2e3509acbd8c06 (diff) |
suspended destructions of pri spans on events
If a DAHDI span disappears, we wish for its representation in Asterisk
to be destroyed as well.
The information about the span's removal may come from several paths:
1. DAHDI sends DAHDI_EVENT_REMOVE on every channel.
2. An extra DAHDI_EVENT_REMOVED is sent on every subsequent call to
DAHDI_GET_EVENT.
3. Every read (including the internal one by libpri on the D-channel)
returns -ENODEV.
Asterisk responsds to DAHDI_EVENT_REMOVE on a channel by destroying it.
Destroying a channel requires holding the channel list lock (iflock).
Destroying a channel that is part of a span requires holding the span's
lock. Destroying a channel from a context that holds the span lock,
while at the same time another channel is destroyed directly, leads to a
deadlock. Solution: don't destroy span while holding the channels list
lock.
Thus changes in this patch:
* Deferring removal of PRI spans in response to events: doomed spans
are collected on a list.
* Doomed spans are removed periodically by the monitor thread.
* ENODEV reads from the D-channel will warant the same deferred removal.
Review: https://reviewboard.asterisk.org/r/3548/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417059 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Diffstat (limited to 'configure.ac')
0 files changed, 0 insertions, 0 deletions