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

Ulf Wiger ulf.wiger@REDACTED
Tue Apr 26 17:23:04 CEST 2011

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) 


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


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.

Ulf W

Ulf Wiger, CTO, Erlang Solutions, Ltd.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110426/0c3203d1/attachment.htm>

More information about the erlang-questions mailing list