The app_lock mutex in chan_agent.c

 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

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.

_______________________________________________
--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