----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3067/#review10430 -----------------------------------------------------------
/branches/12/main/channel.c <https://reviewboard.asterisk.org/r/3067/#comment19887> I think a comment here stating that the locking inversion is "okay" here, as no other thread can obtain the channel prior to linking it into the channels container. Normally, this would be a big ol' red flag :-) - Matt Jordan On Dec. 12, 2013, 11:43 a.m., Joshua Colp wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3067/ > ----------------------------------------------------------- > > (Updated Dec. 12, 2013, 11:43 a.m.) > > > Review request for Asterisk Developers. > > > Repository: Asterisk > > > Description > ------- > > Currently when allocating a channel it is possible for external entities to > become aware of the channel and try to interact with it before it is > completely set up. This occurs because the channel is returned unlocked, and > the caller allocating it is then expected to lock, populate it, and unlock. > This leaves a small window where something else can get the channel. > > The attached change makes it so ast_channel_alloc returns the allocated > channel locked. It is expected that the caller then populates and unlocks. > This leaves no window for something external to get and use it. > > > Diffs > ----- > > /branches/12/tests/test_voicemail_api.c 403703 > /branches/12/tests/test_substitution.c 403703 > /branches/12/tests/test_stasis_channels.c 403703 > /branches/12/tests/test_cel.c 403703 > /branches/12/tests/test_cdr.c 403703 > /branches/12/tests/test_app.c 403703 > /branches/12/res/res_stasis_snoop.c 403703 > /branches/12/res/res_calendar.c 403703 > /branches/12/res/parking/parking_tests.c 403703 > /branches/12/main/pbx.c 403703 > /branches/12/main/message.c 403703 > /branches/12/main/core_unreal.c 403703 > /branches/12/main/channel.c 403703 > /branches/12/include/asterisk/channel.h 403703 > /branches/12/channels/chan_vpb.cc 403703 > /branches/12/channels/chan_unistim.c 403703 > /branches/12/channels/chan_skinny.c 403703 > /branches/12/channels/chan_sip.c 403703 > /branches/12/channels/chan_pjsip.c 403703 > /branches/12/channels/chan_phone.c 403703 > /branches/12/channels/chan_oss.c 403703 > /branches/12/channels/chan_nbs.c 403703 > /branches/12/channels/chan_multicast_rtp.c 403703 > /branches/12/channels/chan_motif.c 403703 > /branches/12/channels/chan_misdn.c 403703 > /branches/12/channels/chan_mgcp.c 403703 > /branches/12/channels/chan_jingle.c 403703 > /branches/12/channels/chan_iax2.c 403703 > /branches/12/channels/chan_h323.c 403703 > /branches/12/channels/chan_gtalk.c 403703 > /branches/12/channels/chan_dahdi.c 403703 > /branches/12/channels/chan_console.c 403703 > /branches/12/channels/chan_alsa.c 403703 > /branches/12/apps/confbridge/conf_chan_record.c 403703 > /branches/12/apps/app_voicemail.c 403703 > /branches/12/apps/app_meetme.c 403703 > /branches/12/addons/chan_ooh323.c 403703 > /branches/12/addons/chan_mobile.c 403703 > > Diff: https://reviewboard.asterisk.org/r/3067/diff/ > > > Testing > ------- > > Placed calls, ran tests, all work as expected. > > > Thanks, > > Joshua Colp > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
