Hello *, while looking at the code i came across a region of code which is unclear to me regarding locking issues. One example is switch_ivr_broadcast in switch_ivr_async.c. This should be the function called by uuid_broadcast() and others. in line 2341 it tries to queue an event to the bleg if it has to... ----- . if ((flags & SMF_ECHO_BLEG) && (other_uuid = switch_channel_get_variable(channel, SWITCH_SIGNAL_BOND_VARIABLE)) . . && (other_session = switch_core_session_locate(other_uuid))) { --- switch_core_session_locate() does a "readonly trylock" on the channel mutex returning NULL if it's unable to aquire the lock, which brings up the following question: If some other thread is currently holding a writelock on the channel, the broadcast is not queued and not retried at a later time at all? I guess it's pretty easy to cause some unexpected behaviour using some endless loop calling "uuid_setvar" or some other race condition where the channel-mutex is write-locked while calling uuid_broadcast (eg. uuid_media?). Could this lead to a problem in "real live" scenarios, or are there other countermeasures despite "chances are one in a million that you hit that small time frame"? thx in advance Beni.
The only time the session is write locked is when its about to be free'd, to make sure nothing holds a valid pointer. Mathieu Rene Avant-Garde Solutions Inc Office: + 1 (514) 664-1044 x100 Cell: +1 (514) 664-1044 x200 mrene@avgs.ca On 27-Aug-09, at 10:08 AM, Benedikt Fraunhofer wrote:
Hello *,
while looking at the code i came across a region of code which is unclear to me regarding locking issues. One example is switch_ivr_broadcast in switch_ivr_async.c. This should be the function called by uuid_broadcast() and others.
in line 2341 it tries to queue an event to the bleg if it has to... ----- . if ((flags & SMF_ECHO_BLEG) && (other_uuid = switch_channel_get_variable(channel, SWITCH_SIGNAL_BOND_VARIABLE)) . . && (other_session = switch_core_session_locate(other_uuid))) {
--- switch_core_session_locate() does a "readonly trylock" on the channel mutex returning NULL if it's unable to aquire the lock, which brings up the following question: If some other thread is currently holding a writelock on the channel, the broadcast is not queued and not retried at a later time at all?
I guess it's pretty easy to cause some unexpected behaviour using some endless loop calling "uuid_setvar" or some other race condition where the channel-mutex is write-locked while calling uuid_broadcast (eg. uuid_media?).
Could this lead to a problem in "real live" scenarios, or are there other countermeasures despite "chances are one in a million that you hit that small time frame"?
thx in advance Beni.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (2)
-
Benedikt Fraunhofer
-
Mathieu Rene