[asterisk-dev] Asterisk Beacon Module Proposal

[George Joseph]

On Tue, Jun 2, 2015 at 6:05 PM, Matthew Jordan <mjordan at digium.com> wrote:
> <snip>
>
> Thanks everyone for the suggestions and ideas. I'm sorry I haven't had
> a chance to reply back to them all until now, but I've had a lot of
> trips and other things pop up, and didn't have a chance to fully
> digest the suggestions and reply back until now.
>
> I've grouped the various suggestions that I had not yet previously
> replied to below.
>
> Suggestion 1: Make the module opt in instead of opt out.
>
> In most cases, I would normally agree with this proposal, as I
> personally prefer an opt in model instead of an opt out model.
> Unfortunately, I'm not sure I can think of a way where this suggestion
> would work with Asterisk - where work implies that a meaningful number
> of people are presented with the option to opt in in a consistent
> fashion.
<snip>

Agreed.

> Suggestion 2: Have Asterisk fork itself on startup
>
> While this seems like a good idea, there are some nasty things that
> can occur when you fork the Asterisk process. Asterisk throws a lot of
> caution to the wind by mixing itself as a forking process and
> multi-threaded process (for a good explanation of why you should never
> do this, read http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-using-them).
> I've personally spent over a month trying to debug the last time we
> held a mutex right when we forked the process, and it was not a fun
> experience.
<snip>

Ok, I get it.

>
> Suggestion 3: Use a separate cron job to trigger the sending
> I think this is a great idea, although I would modify it just slightly.
<snip>

I think this has the same flaw as opt-in.  It'll be up to packagers
and installers to remember to set up the cron job.

How often were you envisioning having the job call home?  I was
thinking at startup and core reload and if that's the case why bother
with an external process and the work that goes with it?  I know
someone mentioned they don't want asterisk crashing because of a flaw
in the beacon but you can say that about any portion of asterisk.  On
startup and reload won't catch realtime changes but I'm not sure we
need that.  Even if you thinking periodical reports, I think it's
still better to to just schedule a repeating task.  Put the beacon in
a module.