[asterisk-dev] Feature Request - new manager commands - 'getcontexts' and 'getcontext'

[Tzafrir Cohen]

On Mon, Jun 11, 2007 at 07:56:39AM +0300, Tzafrir Cohen wrote:
> On Sun, Jun 10, 2007 at 11:33:55PM -0500, Brandon Kruse wrote:
> 
> > 
> > I think we could add this, crunch some numbers, and see what it does.
> > 
> > I know at least for me, and I can speak for pari too, It would make development easier.
> > 
> > Pari mainly, as I only do the janitor and new idea work ;]
> > 
> > 
> > -bkruse
> > 
> > 
> > P.S.
> > 
> 
> > I do realize where others are coming from.....possibly getting choppy 
> > audio because people are clicking tabs to fast, that would be the last 
> > thing I want. If worst comes to worsts we can say its slow because we 
> > want to keep asterisk at the peak performance level. (as it is now.)
> > 
> > The side effects could be horrendous, or very useful. Thats what 
> > testing is for (yes im volunteering :P )
> > 
> 
> Is Asterisk runningin a higher scheduling priority? (-p)
> 
> If so: this configuration task needs no such higher priority. I figure
> that it is not the only task that does not need such higher priority
> (logging comes to mind, or even the whole manager interface).
> 
> But if you're doing an independent parsing of the config files, why not
> run a second "configurator" process in a lower priority?
> 
> Or can scheduling priority apply to threads?

Some linux-specific stuff:

from the man page of sched_setscheduler(), it seems that as of kernel
2.6.12 no special capabilities are required for giving up specia sched.
priority. 

An initial search suggests that this function does apply to threads.

Of course running the manager interface in normal priority means it can
no longer be used to tame an asterisk that has gone bezerk :-(

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