[erlang-questions] gproc for environment data (Re: Regarding `application:get_env` / `application:set_env` race conditions)

Mike Oxford moxford@REDACTED
Tue Apr 26 19:09:46 CEST 2011

Mmm, tasty!

May I offer one small enhancement idea; an alternative-scoped get_env/4 as
an alternative?  You could then say have global scopes fall back to local
scopes (eg, local only configuration settings) or local scopes fall back to
globals (global configuration fallback unless a local is found.)

Also, the documentation states:
"The last instance will be the one that determines the return value."

Is that the last instance defined in "Strategy" or the last instance tried
(eg, first instance that matched) ?

Thanks for the cool new enhancements!


On Tue, Apr 26, 2011 at 8:23 AM, Ulf Wiger

> On 25 Apr 2011, at 14:55, Ulf Wiger wrote:
> I will not present an alternative at this time - although your question
> gave me an idea. I'll have to think it through a bit first.
> Ok, so here goes:
> I have added some functions in gproc (version 0.2.6) for more uniform
> handling of environment settings:
> gproc:get_env(Scope, App, Key, Alternatives)
> https://github.com/esl/gproc/blob/master/doc/gproc.md#get_env-4
> checks for a cached value (a global or local gproc property) corresponding
> to the requested value; if not found, it tries a list of alternatives,
> including OTP application env vars, os:getenv/1, init:get_argument/1 or even
> mnesia. Inheriting a parent's, or other process's cached value is also
> possible. If gproc:get_set_env/4 is used, the result is also cached.
> There is also a write-through option, gproc:set_env/5, which modifies the
> cached value *and* the underlying "original" (e.g. app env, os environment,
> or mnesia).
> *https://github.com/esl/gproc/blob/master/doc/gproc.md#set_env-5*
> Apart from offering a reasonably uniform and declarative method of fetching
> environment data, the values are also presented and indexed in a way that
> simplifies system inspection and debugging. If used consistently, gproc can
> help notify users of a configuration value that it has changed, simply by
> calling
> gproc:send({p,Scope, {gproc_env, App, Key}}, UpdateMessage).
> according to the principle that processes that rely on static data in
> non-stop systems, need to be prepared for that data to change over time.
> BR,
> Ulf W
> Ulf Wiger, CTO, Erlang Solutions, Ltd.
> http://erlang-solutions.com
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110426/805fd6c7/attachment.htm>

More information about the erlang-questions mailing list