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

[Jack Storm]

BJ Weschke wrote:
> 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
> 

After finding the time to put some thought in to this today, I really 
think chan_agent neeeds to be broken up. Now BJ gave me the idea while 
talking on #asterisk-bugs today (06/23), but My idea is his inverted.

BJ suggested the following:

 >honestly - I think the way to do this is to handle the who's logged 
 >in/logged out and all the other stuff would be best via a res_*
 >and then callback stuff can actually work within the channels they 
were >designed to work within
 >and chan_agent can go back to being what it was originally designed as
 >a channel driver w/o callbacks

My Idea is this:

Remove all of the always connected part of chan_agent, and let
chan_agent be a "login proxy channel" (thats what Agents are) then
create a new channel driver called chan_tunnel (tech:Tunnel/) to handle
the old chan_agent always connected. Then change the way agents.conf
is defined, and make it more like the other channel drivers, so that
each agent is allowed to be a [peer|user|friend], so when we get 
realtime config in we can link tables across vm,agents,(endpoints).

Think of Tunnel as Channel over Channel, where features are allowed
in an active chan.