[asterisk-dev] The app_lock mutex in chan_agent.c

[BJ Weschke]

 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/