[asterisk-dev] mutual exclusive timing modules [was russell: trunk r122977 - /trunk/configs/modules.conf.sample]

[Tzafrir Cohen]

(Commit names don't make nice subjects. Anyway,)

On Mon, Jun 16, 2008 at 09:06:26AM -0500, Russell Bryant wrote:
> 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.

This is not the first time we have a pair of mutual-exclusive modules.
There are also chan_oss and chan_alsa (and chan_console?) .

I wonder if there was a way for the loader to quitely avoid loading one
if the other is already loaded.

> 
> 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.

OK, so this also implies only one timing module. I wonder if we can also
have "only one console module".

> 
> 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.

-- 
               Tzafrir Cohen
icq#16849755              jabber:tzafrir.cohen at xorcom.com
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir