[Kamailio-Devel] [SR-Dev] register_timer versus register_timer_process
Jan Janak
jan at iptel.org
Tue Mar 10 02:27:22 CET 2009
On 09-03 21:19, Ovidiu Sas wrote:
> So what is the outcome of this discussion?
> Are we going to port the 'register_timer_process' from kamailio into
> the sip-router?
> This is a blocker for porting certain modules from kamailio to sip-router.
As far as I can tell, the timer process in kamailio serves the same
purpose as the slow timer process in ser, I would thus recommend to
convert everything that uses register_timer_process in kamailio to use
the slow timer process in ser.
Of course I haven't investigated all the code in k. in detail, but it
seems to me that the two mechanisms server the same purpose, given
that k. doesn't have the slow timer process and we don't have separate
timer processes in ser.
Jan.
> On Fri, Mar 6, 2009 at 10:31 AM, Andrei Pelinescu-Onciul
> <andrei at iptel.org> wrote:
> > On Mar 06, 2009 at 14:53, Jan Janak <jan at iptel.org> wrote:
> >> On 06-03 15:44, Daniel-Constantin Mierla wrote:
> >> > Hello,
> >> >
> >> > On 03/06/2009 03:16 PM, Jan Janak wrote:
> >> >> Hello,
> >> >>
> >> >> There are two functions in the implementation of timers in kamailio,
> >> >> register_timer and register_timer_process. What is the different between those
> >> >> two functions and which should be used when?
> >> > the first one is to register a function to be executed by the main timer
> >> > process. Second is to create a new time process dedicated to run a
> >> > specific function.
> >> >
> >> >> I noticed that, for example, the
> >> >> htable module seems to be using them interchangeably, there is a modparam
> >> >> which controls which function is gonna be used.
> >> >>
> >> >> Can we replace register_timer_process with register_timer function from the
> >> >> sip-router core?
> >> >>
> >> > Doesn't ser support to create a new timer process? How is it in the
> >> > timer module? Is the route executed by the main timer process?
> >> >
> >> > Idea behind dedicated timer process is to be able to execute timely
> >> > operations there without affecting the main timer which deals with
> >> > retransmissions, etc.
> >>
> >> I see, we have the concept of slow and fast timers, so in that case the stuff
> >> that needs its own timer process should probably be executed from within the
> >> slow timer handler.
> >
> > It depends, if it's very slow (e.g. can block for long periods of time
> > in the timer handle), it will be better to run in its own process.
> >
> > After a quick look at what register_timer_process(f, p, i, f) does, it seems
> > it's equivalent with:
> >
> > if (fork()==0) { sleep(interval); function(param); }
> >
> > (meaning one can have only 1 timer in one timer process, I haven't seen
> > a way to register more)
> >
> > If you only need 1 timer in your extra timer process, this can be done
> > in sr like above, but replacing fork() with fork_process(...).
> > If you need several timers and you want to be able to register/delete
> > them dynamically, you should use local_timer (local_timer is a
> > generalized very efficient timer, designed to be run "by hand" in a
> > single process).
> >
> > #include "local_timer.h"
> >
> > struct local_timer lt;
> >
> > if (fork_process(...,"my timer", ...)==0){
> > /* init */
> > init_local_timer(<, get_ticks_raw());
> > /* add timers */
> > local_timer_init(t1, handler1, param, 0);
> > local_timer_add(<, t1, S_TO_TICKS(10) /* 10 s*/, get_ticks_raw());
> > /* as many times as needed */
> > while(..){
> > /* do something, e.g. poll some fds, read or even sleep(..) */
> > /* periodically call local_timer_run which checks if any timer
> > has expired and is so runs it */
> > local_timer_run(<, get_ticks_raw());
> > /* add more timers or delete some of them */
> > local_timer_del(&tl, t3);
> > ...
> > }
> > }
> >
> >
> > Andrei
> >
> > _______________________________________________
> > Kamailio (OpenSER) - Devel mailing list
> > Devel at lists.kamailio.org
> > http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
> > http://lists.openser-project.org/cgi-bin/mailman/listinfo/devel
> >
More information about the Devel
mailing list