[Freeswitch-dev] Need some explainations about method switch_core_session_run(switch_core_session_t *session) in switch_core_state_machine.c

[Anthony Minessale]

On Wed, Jan 6, 2010 at 9:20 AM, Alex To <tonhudung at gmail.com> wrote:

>  Hi,
>
>
>
> First of all, pardon my English. English isn’t my native language J.
>
>
>
> I am reading the method switch_core_session_run(switch_core_session_t
> *session) and I would be really appreciated if someone could shed some light
> on how the method works. Below is the logic according to my understanding:
>
>
>
> 1.       LINE 303:              while ((state =
> switch_channel_get_state(session->channel)) != CS_DESTROY)
>
> ð  if state is CS_DESTROY return and do nothing ?
>
>
>
state typically starts at CS_NEW the loop runs until state destroy is
reached




> 2.       Inside if (state !=
> switch_channel_get_running_state(session->channel) || state >= CS_HANGUP)
>
> {
>
> …
>
> }
>
> a.       LINE 308:              state !=
> switch_channel_get_running_state(session->channel) || state >= CS_HANGUP
>
> ð  to check if channel->state and channel->running_state not equal. This
> is to avoid running the STATE_MACRO multiple times. However I don’t
> understand why do we need (state >= CS_HANGUP) ?.
>

Once we are >= HANGUP we dont want to do that test anymore.


> b.      Inside STATE_MACRO code block
>
>                                                                i.      LINE
> 229:              midstate = state
>
> ð   to save the current state.
>
>                                                              ii.      LINE
> 231:              if (!driver_state_handler->on_##__STATE ||
> (driver_state_handler->on_##__STATE(session) == SWITCH_STATUS_SUCCESS)
>
> ð  to check either endpoint_interface->state_handler is NULL or return
> SWITCH_STATUS_SUCCESS so it will continue to execute handlers in
> session->channel, runtime.state_handlers and core standard state handlers.
> It means if the condition is not true, channel->state_handlers,
> runtime.state_handlers and core standard state handlers will NOT be executed
> at all ?
>
>                                                             iii.      LINE
> 246:              if (!proceed) global_proceed = 0;
>
> ð  If something wrong in the previous while loop, do not run core standard
> state handlers ?
>
yes the endpoints have the power to veto state handlers from being called




>                                                            iv.      LINE
> 247:              proceed =
> 1;
>
>
> LINE 248:              while (do_extra_handlers && proceed &&
> (application_state_handler = switch_core_get_state_handler(index++)) != 0) {
> …}
>
> ð  Since we set proceed = 1, do we still need (&& proceed) inside the
> condition in while loop ?
>
yes because proceed can become 0 within that loop



>                                                              v.      LINE
> 260:              if (!proceed || midstate !=
> switch_channel_get_state(session->channel)) global_proceed = 0;
>
> ð  If not proceed or the channel state has changed by some of the state
> handlers executed earlier, do not execute core standard state handler ?
>
Again, veto power.


>                                                            vi.      LINE
> 266:              while (silly)
>
> ð  silly is never changed, does it mean we could go into an endless while
> loop ?
>
>
>
Its to stop the compiler from getting mad, that's why it's called silly its
specific to using a while loop inside a macro



> Sorry for the long email and some questions are probably dumb but I am
> trying to understand about FreeSwitch, especially the core and the core
> state machine. If it is documented somewhere about the workflow happening
> inside FreeSwitch, please enlighten me as what I am doing now is to read the
> code line by line and figure out which may not be the most efficient .
>
>
>

Why are you digging into this code? do you have some problem you are
attempting to solve?
The most important thing is that code like this that has taken so long to
perfect, even if there could be improvements, is hard to even look at
without causing regressions.  So I'm curious what you were looking for.



> Thank you for reading this
>
>
>
> Regards
>
>
>
> Alex To
>
>
>
>
>
> _______________________________________________
> FreeSWITCH-dev mailing list
> FreeSWITCH-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>
>


-- 
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:+19193869900
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20100106/74405c51/attachment.html