Short of a dev conference call earlier this week to discuss, based on JackEStorm's posts in #asterisk-bugs about his research into deadlock issues with chan_agent/app_queue I've now also taken a harder look at chan_agent.c this past week and I'm coming up with blanks at this point trying to understand why we need to make use of the app_lock mutex at all on a chan_agent channel when the agent is working in callback mode. When not in callback mode, we definitely need this to forego competition between the login app and the "owning" channel, but in callback mode, the login app has already long ago exited the scene and there seems to already be adequate protection that exists today within the code that prevents a second call from getting built on top of an agent_pvt that already has an active call up. With the ever changing ways that we're trying to manage transfers and other complex operations within the channel technologies, it seems like it's becoming more common place that the thread handling agent_hangup(...) for a given agent channel is not always going to be the same thread that locked the app_lock mutex within agent_request(...). That being the case, I'm seeking advice/comments on doing away with the use of the app_lock mutex with agent channels when in call back mode.
Comments greatly appreciated. BJ -- Bird's The Word Technologies, Inc. http://www.btwtech.com/ _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev