30 Mar
2007
30 Mar
'07
11:02 a.m.
On Fri, 2007-03-30 at 16:39 +0200, Jiri Kuthan wrote:
That is an intersting one. Do you have any pointers to the relevant
parts of code or to which structural changes enables that ?
Yes, I understand that now.
OK, OK, this one was not very insightfull from me :-)
Well actually I think so. I am not sure what else you
could call for a software to be of
radical change than complete change of the underlying data structures and associated
algorithms :-). (referring to the timer subsystem)
Right, after looking at the code. What I was saying is ".... and it is
not immediatly evident ...", by "immediatly" I meant "at first
look",
"just by looking at the docs" ...
They changed a bit parameters to configure various
timers from config file, and they of course retained the ability to change fr_timer and
fr_inv_timer (interesting for controlling max ringing duration) on-the-fly on a
per-transaction basis.
The key thing (in addition to minor) is elimination of race conditions. They also are currently developping a very
interesting module called "timer", which provides the ability to set timers
on-the-fly, with callback implemented as routes called when the custom timers fire. This
seems pretty simple in their model, the timer module being only 408 lines long (but I
can't tell if this works already or not).
Yes, that's a cute thing but I was previsouly merely referring to the under-the-hood
kind of things. An other puzzling fact is that SER's
implementation of timers in tm module is about half the size as OpenSER's .... I'm
not sure we can infer anything from this fact, still it made me curious.
Neither am I. 