[asterisk-dev] [Code Review] Split up SIP UDP receiving and proceeding

[Russell Bryant]

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


I haven't looked at the code yet, but as a general comment, if you want to split up UDP packet processing and scheduler processing, I think moving the scheduler into its own thread makes more sense.  That way, you don't have to do so much copying of data and then signaling another thread for each packet that comes in.

Moving the scheduler to its own thread shouldn't be too hard.  I've done it once before, but got crashes with load testing.  It was a long time ago, though.  There is an ast_sched_thread API you can use to automatically handle the scheduler thread.  However, it does require touching a lot of places in chan_sip that schedule callbacks.

I've actually been thinking about re-doing how ast_sched_thread works.  I'd like to get rid of the sched_thread data structure and instead just optionally have the thread data in the sched_context.  I'd like to be able to use all of the same API calls for the scheduler, but just have an optional API call to start running a thread on a scheduler context.  If we did that, the changes to chan_sip to put the scheduler in its own thread would be _trivial_.

- Russell


On 2010-10-09 16:31:06, schmidts wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/970/
> -----------------------------------------------------------
> 
> (Updated 2010-10-09 16:31:06)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> i need help cause i got a little stuck about this.
> with this patch the receiving and proceeding of sip packages over udp is split up and also in do_monitor the order how the ast_io_wait function is called.
> my idea is, if a slow handling in handle_request happens it would not block further incoming packets and scheduled events.
> 
> my problem is that the thread i have created which waits for requests to proceed creates a cpu load of 100% and i dont know why.
> i have tried using ast_cond_wait on this but i cant get this run, cause i cant hit the right locking order. :(
> 
> have i missed something essential here or why does this thread needs that much cpu time?
> 
> this patch is against 1.6.2 branch cause i need it for 1.6.2. if this works as i hope i moved it against trunk.
> 
> 
> Diffs
> -----
> 
>   branches/1.6.2/channels/chan_sip.c 291037 
> 
> Diff: https://reviewboard.asterisk.org/r/970/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> schmidts
> 
>