[asterisk-dev] [Code Review] Make new SIP work make use of threadpool

[jcolp]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2305/#review7804
-----------------------------------------------------------



/team/group/pimp_my_sip/channels/chan_gulp.c
<https://reviewboard.asterisk.org/r/2305/#comment14798>

    I'd reverse this logic. It looks nicer. Looks are important, you know.



/team/group/pimp_my_sip/channels/chan_gulp.c
<https://reviewboard.asterisk.org/r/2305/#comment14804>

    Failure case here causes different behavior than before. Previously whatever is executing the call would have received an error and now it will not. I think we'll have to queue up a hangup with a suitable cause code instead.



/team/group/pimp_my_sip/include/asterisk/res_sip.h
<https://reviewboard.asterisk.org/r/2305/#comment14803>

    s/pushe/pushed/



/team/group/pimp_my_sip/include/asterisk/res_sip.h
<https://reviewboard.asterisk.org/r/2305/#comment14802>

    We could probably make this "just work" in case someone forgets by using pj_thread_is_registered



/team/group/pimp_my_sip/res/res_sip_session.c
<https://reviewboard.asterisk.org/r/2305/#comment14799>

    You fixed it! I noticed this when Blink was set up, it was trying to SUBSCRIBE to stuff and received no response due to this.



/team/group/pimp_my_sip/res/res_sip_session.c
<https://reviewboard.asterisk.org/r/2305/#comment14800>

    Fairly certain this log message is actually incorrect. It'll just use the old local SDP for the negotiation.



/team/group/pimp_my_sip/res/res_sip_session.c
<https://reviewboard.asterisk.org/r/2305/#comment14801>

    I'd probably take the approach of sending the refcounted session in and use that to get the inv_session so we don't have disturb pjsip refcounting.


- jcolp


On Jan. 31, 2013, 1:01 p.m., Mark Michelson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2305/
> -----------------------------------------------------------
> 
> (Updated Jan. 31, 2013, 1:01 p.m.)
> 
> 
> Review request for Asterisk Developers, Matt Jordan and jcolp.
> 
> 
> Summary
> -------
> 
> This changeset introduces threadpool usage into the new SIP work. Function calls that originate from the Asterisk core (such as channel callbacks) and from PJSIP's event handling thread (such as incoming request/response callbacks) now push their work into the SIP threadpool.
> 
> The benefits to this changeset are:
> 1) Frees up PJSIP event handling threads so that they can process more incoming SIP messages at a time
> 2) Places similar SIP tasks into their own task queue so that they can be completed in sequence, thus limiting resource contention. So far, session tasks are the only ones that use this mechanism
> 
> I added a new API call called ast_sip_push_task_synchronous(), that allows for you to push a task to a servant and block until the task completes. This is used in several cases where Asterisk threads need to make use of a PJSIP feature but need to have the result of the pushed task before returning. A good example of this is gulp_request() in chan_gulp. We need to call some PJSIP routines to set up a UAC and a dialog and such. But we also need to return a new ast_channel before gulp_request() returns.
> 
> Please have a look over this to see if I've made any obvious mistakes (e.g. memory leaks, tasks being not being executed in the threadpool when they should be)
> 
> 
> Diffs
> -----
> 
>   /team/group/pimp_my_sip/channels/chan_gulp.c 380670 
>   /team/group/pimp_my_sip/include/asterisk/res_sip.h 380670 
>   /team/group/pimp_my_sip/include/asterisk/res_sip_session.h 380670 
>   /team/group/pimp_my_sip/include/asterisk/threadpool.h 380670 
>   /team/group/pimp_my_sip/main/taskprocessor.c 380670 
>   /team/group/pimp_my_sip/main/threadpool.c 380670 
>   /team/group/pimp_my_sip/res/res_sip.c 380670 
>   /team/group/pimp_my_sip/res/res_sip.exports.in 380670 
>   /team/group/pimp_my_sip/res/res_sip/config_transport.c 380670 
>   /team/group/pimp_my_sip/res/res_sip/sip_options.c 380670 
>   /team/group/pimp_my_sip/res/res_sip_session.c 380670 
> 
> Diff: https://reviewboard.asterisk.org/r/2305/diff
> 
> 
> Testing
> -------
> 
> I've run the OPTIONS test in the testsuite and can confirm that Asterisk shutdown does not crash Asterisk any more. I also ran incoming and outgoing calls and ensured that they completed correctly with no issue.
> 
> 
> Thanks,
> 
> Mark
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130205/6b913305/attachment-0001.htm>