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
3451d6a72d