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