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

[Ciprian Dorin Craciun]

On Tue, Apr 26, 2011 at 18:23, Ulf Wiger <ulf.wiger@REDACTED> wrote:
>
> 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:

    Nice, quite feature-full.


> 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).

    Though: it would be nice to be able to specify a generic function
to be used to fetch the value, like:
~~~~
    SomeFun = fun (Key) ->
        case <<some_expression>> of
            <<some_pattern>> -> {ok, some_value};
            <<some_other_pattern>> -> undefined
        end
    end,
    gproc:get_env (l, some_app, some_key, [app_env, SomeFun,
{transform, {erlang, list_to_atom}, os_env}]).
~~~~
    * the ability to specify an arbitrary function in the chain (that
behaves just like `application:get_env`);
    * the ability to specify a "transformer" for the value -- for
example os_env would return always strings, but I would expect an
atom;


> 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

    Is this message {p, Scope, {gproc_env, ...}} ... sent
automatically by the current gproc version? (I've never used gproc,
but I've wanted for some time to see what it can offer.)


    Thanks,
    Ciprian.