I have a program that increments a number in a variable: the variable currently is saved in memory, but I realize that heroku cycles the worker randomly, and that would mean my variable in memory would be lost. So, I intend to turn it into an environment variable; but, I don't know how to use it in my code.
The variable in my python code: cum_num = 98.
How would this work if I made an exact cum_num, but as a heroku environment variable?
Related
I face a situation where I need to declare a global variable so every file of Linux source code can reference it. As much as I know, Linux is a Monolithic kernel, so this can be done. So I add the global variable to the init/main.c file. However, when I use extern .. in other files, the compiler says undefined reference. Any help?
Update
The more file can access, the better. To be more concrete, I'm tracing the execution times of certain function, so I define a global variable, everytime the function executes, I'll add one. This is the most straightforward way to meet my demand.
It seems that memory are allocated for a variable only after running its initializer in a session.
For some reason, I have to use some temporary variables. For example there isn't enough memory to run a big batch at one time, so I need to store the temporary gradients in extra variables. When I don't need this variables anymore, I want to make it at the uninitialized state (the state that no memory is allocated for it). Cause there is no memory for other computations.
The method I use now is to initialize variable in a session, then close this session and create a new session, where I have to fetch the persistent variables value in python ndarray( cpu memory),and initialize those variable in the new session, which is verbose.
So I'd like to know is there any method to free a variable in tensorflow.
Reading and writing environment variables in Node.js is done using the process.env object.
For instance:
process.env.foo evaluates to the env var foo
process.env.bar = 'blah' sets the value of the env var bar to blah
delete process.env.baz deletes the environment variable baz
From trial and error, and the lack of a callback, I assume that these actions are synchronous, but I found no reference to it process.env documentation.
Is env var access synchronous or asynchronous in Node.js?
Addendum: Why I believe this question to be non-trivial
Following the comments: Reading and writing the environment variables might mean that the process needs to communicate with the operating system, or perform some sort of blocking I/O operations.
Therefore, it makes sense to ask whether the environment variables are stored as a local object in memory without any synchronization, or otherwise sent to the operating system in a blocking manner.
Moreover, implementation may vary between operating systems and the official documentation lacks any promise to a non-blocking operation.
I think the "synchronous"/"asynchronous" may be a bit misleading.
I guess the actual question is: Is reading from or writing to process.env expensive? Does it perform a blocking operation with the operating system?
The short answer is Yes, it can be expensive.
For more background info and how much it can impact some apps, see this GitHub issue. There it was already stated that the documentation should be updated to make it clear that accessing process.env is slow in 2015 but it hasn't happened yet.
You can actually see the implementation for process.env in the node.js source code where it's obvious that any access will call one of the functions defined from here onwards.
Note: At the time of writing, this was defined in node.cc in a more straight-forward way. The links above still point to the old implementation. Newer versions of node have process.env implemented in a separate file node_env_var.cc which can be found here, but it has more encapsulation, making it harder to follow for the purpose of this explanation.
Depending on the platform, this may have more or less of an impact.
It becomes most obvious on Windows, because there you can view a process' current environment from the outside (while in Linux, the /proc/.../environ file will retain its original contents when the environment was changed with setenv).
For example:
node -e "process.env.TEST = '123'; setInterval(() => {}, 1000);";
This will start a node process which creates a TEST environment variable in the current process' environment and then wait forever.
Now we can open a tool like Process Explorer or Process Hacker and look at the environment of the node process:
And lo and behold, the variable is there. This proves in another way that writing to process.env does in fact access the operating system.
Also, because the object actually queries all data from the OS, it means that it even behaves different than a normal object. Again, Windows example (because it's most quirky):
Windows matches environment variables case-insensitive.
> process.env.TEST = '123'
'123'
> process.env.tEsT
'123'
Windows has hidden environment variables starting with = which cannot be changed through normal means and which are not enumerated. node.js replicates these semantics. The =X: variables in particular represent the current directory in specific drives (yes, Windows stores them per drive).
> Object.keys(process.env).filter(k => k === '=Z:')
[]
> process.env['=Z:']
'Z:\\'
> process.env['=Z:'] = 'Z:\\Temp'
'Z:\\Temp'
> process.env['=Z:']
'Z:\\'
> process.chdir('Z:\\Temp')
undefined
> process.env['=Z:']
'Z:\\Temp'
Now, somebody might think (similar to what was proposed in the GitHub issue that I linked) that node.js should just cache process.env in an actual object, and for child process creation read the environment from the cached object. This is not advisible for the following reasons:
They would need to copy the semantics of the underlying platform and reimplement them. As you can see in the above example for Windows, this would at some point end up in intercepting chdir and trying to automatically update the relevant =X: variable of the affected drive (and then it wouldn't work if a native plugin would change the current directory), or access the OS only for some variables, and therein lies madness and huge potentional for obscure bugs.
This would break applications which read a process' environment from the outside (like Process Explorer), as they would see incorrect values.
This would create inconsistencies if a native module would access the environment variables in its own from C++ code, because they would now have a different state than the cached object.
This would cause childprocesses to not inherit the correct variables if the child process were started by a native module (for the same reason as above).
This should also explain why it is a bad idea to do process.env = JSON.parse(JSON.stringify(process.env)) in your code. For one, it would break case-insensitivity on Windows (and you can't possibly know what modules which some other module requires may depend on that), and apart from that it would of course cause tons of other problems as described above.
Actually it is an normal object to make you could get the environment variables of current process, after all them are just some variables for carry some setting to a program. Nodejs just set a normal object for them after nodejs program read them. Although documentation not write them but it write this is an object and following things:
It is possible to modify this object, but such modifications will not
be reflected outside the Node.js process. In other words, the
following example would not work:
$ node -e 'process.env.foo = "bar"' && echo $foo
While the following will:
process.env.foo = 'bar';
console.log(process.env.foo);
Assigning a property on process.env will implicitly convert the value to a string.
This is enough to explain your problem.
I have a process which is supposed to use OpenMP, and I would like to verify whether an environment variable is set to the expected value.
I tried to read the environment variables of my program's process but can't find any OpenMP variable.
My question is: Can I see the OpenMP environment variable within my process with a terminal?
Is there a way to get an OpenMp status using a terminal?
Since you are seeing other environment variable but not the OpenMP ones, it could be because the environment variable OMP_DISPLAY_ENV is not set. If it`s not, then nothing will be shown.
I have a script that exports an environment variable and starts some subscripts.
export LOGLEVEL="1"
/home/myuser/bin/myscript1.sh
/home/myuser/bin/myscript2.sh
LOGLEVEL is available to the processes started from the subscripts. How can I change the environment variable LOGLEVEL?
I have tried to set the variable with export LOGLEVEL="5" but that`s not working.
In general, you can only influence a process's environment variables at the time the process starts up. If you need to communicate a change to a running process, the environment isn't the right tool.
However, this question has some answers that suggest ways to overcome this limitation.
Edited to add in light of discussion in the question's comments: A fairly good way of communicating occasionally changing setup to a running process is to designate a configuration file where the LOGLEVEL value is set, send a SIGHUP to the process, and have the process reread the configuration file upon receipt of SIGHUP.