Sure, I can connect to the database for each thread. That doesn't ensure thread
safety tho. How can I be sure that there's not state information in DBD/DBI
that's being shared (and possibly corrupted) between all perl threads? The Perl
DBI docs specifically say it isn't thread safe.
What state am I speaking of? A good example is findme/followme. You want a
database table that lists for a given extension, a new list of forwarded
extensions to try. You want to execute a query, get the forwarded number to try
to dial it. If you pass control back to the dialplan, and attempt to dial the
number from there, if it fails to answer, then you have to call the AGI script
again and execute another query, this time returning the second number. When
you execute this second query, how are you going to maintain the state and
remember that you have advanced to the next number/row in the table?
Obviously if you keep control inside the AGI script, and dial from there, you
can maintain the state in the scripting language. If you pass control back to
the dial plan, I don't know how you'd do it. I ask because when I posed the
question before about whether or not you should execute queries in the AGI and
return control to the dialplan, or keep control in the AGI, I was told that
it's best to return control to the dial plan and Dial() from there.
Doug
-----Original Message-----
From: Sig Lange [mailto:[EMAIL PROTECTED]
Sent: Wed 1/25/2006 8:19 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Cc:
Subject: Re: [Asterisk-Users] Fast AGI Options. Eeeek!
On 1/25/06, Douglas Garstang <[EMAIL PROTECTED]> wrote:
Some questions regarding calling Fast AGI from the dial plan.
Considering that the server side of the Fast AGI has to be able
to a) use threading and b) connect to MySQL, this causes some serious
limitations. I'm not a C programmer, so development options are either perl or
python.
In ref to using perl, You can't connect to the database for each
thread?
It appears that the perl DBI isn't thread safe, so that rules
out Perl. Python's database interfaces are apparently thread safe _to a point_,
so that seems like a better idea. I'd prefer to stick with Perl because I am
more familar with it, but oh well...
Has anyone done this? Was it successful? Did you control the
entire dial plan logic from the AGI, or did you just make AGI calls as
necessary to look certain things up? What about iterative queries where you had
to maintain the state from one call of the AGI to the next? Did you stay in the
AGI until control was complete, or did you return control to the Asterisk dial
plan after every lookup, where it performed some actions, and then you returned
to the AGI.... if this was the way you did it, how did you maintain the
database state from one call to the next???
Anytime I decide to include AGI into an application, I try to keep most
of the code and logic inside the AGI. I have successfully written FastAGI
applications in python, and it was a good experience.
What state are you speaking of? I don't quite follow.
Did you have multiple AGI scripts, broken down by function, or
did you have one AGI script that was passed a value that specified it's
function, and then you branched into some section of this all-encompassing AGI
based on the value passed?
Thanks,
Doug.
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
Asterisk-Users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
--
Sig Lange
http://www.signuts.net/
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
Asterisk-Users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
