[prev in list] [next in list] [prev in thread] [next in thread] 

List:       asterisk-dev
Subject:    Re: [asterisk-dev] [svn-commits] tilghman: branch 1.4 r87120
From:       Russell Bryant <russell () digium ! com>
Date:       2007-10-27 15:37:40
Message-ID: 47235B44.9030004 () digium ! com
[Download RAW message or body]

Tilghman Lesher wrote:
> ARRAY - Sets variables, but could just as easily create globals.  Autoservice
> might be needed, though, if one of the variables set is a function.
> Conditional autoservice.
> REALTIME - Database operations could delay.  Conditional autoservice.
> func_odbc - uses the channel to set parameters, so a channel should be
> created, if NULL is passed.  Also, database access could be slow, so
> autoservice should be added.
> GROUP* - iffy.  However, since it depends upon a list lock that could get
> lots of contention on a busy system, we should probably add autoservice.
> However, since setting/checking GROUP on a nonexistent channel is
> nonsensical, the autoservice should be conditional.
> GLOBAL - Same as GROUP, add conditional autoservice (especially
> since global variables don't need an associated channel).
> STAT - If the file is located on a remote filesystem, there could be a delay
> returning.  However, a channel is not strictly needed, so conditional
> autoservice.
> ENUMLOOKUP, TXTCIDNAME - Both are DNS lookups which may involve
> delay, but neither really need a channel.  Conditional autoservice.
> CUT - needs a channel, but no delay is possible.  No autoservice needed.
> CURL - delay but channel not needed.  Conditional autoservice.
> 
> So in summary, in all but one case (func_odbc), we should add autoservice,
> but conditionally, and in that last case, we need to ensure that the channel
> exists, so autoservice should be added all the time.  Does this sound
> reasonable?

Yes, it does sound reasonable.  I also agree with your assessment of which other
functions could benefit from autoservice.  As you pointed out, GROUP* and GLOBAL
are the only ones where it isn't obvious.  I think if you used the argument for
potential lock contention as the reason for adding it, then there is another
good number of them that would be added to the list.

I think that we should leave all of these alone.  None of these things should be
held up by a lock long enough that autoservice would be able to process any more
than a single media frame[1].

[1] If autoservice starts at time t, and media frames are arriving every 20ms,
the first media frame arrives between t and (t + 20) ms.  So, the second will
arrive between (t + 20) and (t + 40) ms.  If waiting that long for any lock is
considered normal, I'd like to know about it.  :)

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

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev
[prev in list] [next in list] [prev in thread] [next in thread]