From c978cc1e2646874c91ad721ad6f989f2af7560da Mon Sep 17 00:00:00 2001
From: Russell Bryant <russell@russellbryant.com>
Date: Sat, 26 Jul 2008 14:57:50 +0000
Subject: [PATCH] Re-work comment about how device state changes are processed
to be a bit more clear
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@133943 65c4cc65-6c06-0410-ace0-fbb531ad65f3
---
main/devicestate.c | 21 +++++++++++++++------
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/main/devicestate.c b/main/devicestate.c
index 9a2881a3ff..b27413cfb2 100644
--- a/main/devicestate.c
+++ b/main/devicestate.c
@@ -476,12 +476,21 @@ int ast_devstate_changed_literal(enum ast_device_state state, const char *device
{
struct state_change *change;
- /* If we know the state change (how nice of the caller of this function!)
- * then we can just generate the event. Otherwise, we have to go through
- * a crap ton of extra work to go figure out what the state change is.
- * We queue the fact that the state has changed up for another thread to
- * go figure out, which it does by calling into the channel driver if it
- * can, or by walking through the active channel list. */
+ /*
+ * If we know the state change (how nice of the caller of this function!)
+ * then we can just generate a device state event.
+ *
+ * Otherwise, we do the following:
+ * - Queue an event up to another thread that the state has changed
+ * - In the processing thread, it calls the callback provided by the
+ * device state provider (which may or may not be a channel driver)
+ * to determine the state.
+ * - If the device state provider does not know the state, or this is
+ * for a channel and the channel driver does not implement a device
+ * state callback, then we will look through the channel list to
+ * see if we can determine a state based on active calls.
+ * - Once a state has been determined, a device state event is generated.
+ */
if (state != AST_DEVICE_UNKNOWN) {
devstate_event(device, state);
--
GitLab