[asterisk-dev] Feature Request - new manager commands -
'getcontexts' and 'getcontext'
tzafrir.cohen at xorcom.com
Mon Jun 11 00:29:00 CDT 2007
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.
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 :-(
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
More information about the asterisk-dev