[asterisk-dev] [asterisk-commits] russell: trunk r122977 - /trunk/configs/modules.conf.sample

[Russell Bryant]

Kevin P. Fleming wrote:
> I'd suggest putting explicit 'load =>' lines for these, as it shouldn't
> hurt to load multiple modules; the first one to successfully register
> timing functions will take precedence, and the rest will fail to load
> because there is already a functional module.
> 
> Given that, listing res_timing_dahdi first will make it the first shot
> at providing timing, and then the backup will be res_timing_pthread.
> However, this could result in some annoying messages on the console, and
> if res_timing_dahdi didn't get built, I'm not sure what will happen with
> an explicit 'load =>' line in the module loader.

Well, by luck due to alphabetical order, res_timing_dahdi will get 
loaded first if you put nothing in the configuration file.

Also, it looks like nothing happens if you put "load => 
something_that_does_not_exist.so".  I think I'd rather have a big error 
message, though.

I'd like to come up with something that makes sure we use the best 
timing source, without relying on configuration or luck.  The only thing 
I have thought of is letting modules also register a score that 
indicates how good of a timing source they are, relative to each other. 
  Then, as they get loaded, we could ensure we're using the best one.

The only part that would be tricky with that is handling when a better 
timing source gets loaded when another one is already in use.  It would 
have to wait until no timers were open before it could switch it out, I 
guess.

-- 
Russell Bryant
Senior Software Engineer
Open Source Team Lead
Digium, Inc.