Then it follows that:
"inject once at start" == "Inject once after 0.1 seconds, then"
Question 1: What delay do you recommend specifying ?
It is written in the help of the inject node: "It can also be configured to inject once each time the flows are started."
Question 2: What is the difference between flows are started and Node RED are started ?
Correct. When the flow file is deployed/saved it is written out in tab order. So when read/started the first tab gets loaded and run first. Normally a delay of .1 s is ok to allow connected nodes to also start, but in this case where the OP just wants to setup the environment the timeout can be set to 0
Node red starts and then it starts the flows. If you start node-red by using node-red --safe
it starts node-red but does not start the flows. In that mode the editor works but no flows are running.
To add to what others have said, the flows are also started each time you hit the deploy button (assuming you do a 'full' deploy and not one of the modified flows/nodes types of deploy).
A further point. If you have code that relies on a context variable then it should always check that the variable has been setup before using it, and if it has not then take appropriate action, using a default, or doing nothing or whatever is appropriate.
That is about node red, not 'threads'. Node red is a process of (generally) one thread. It provides the node red editor capability and also runs flows, all within that thread.
I completely agree with you.
It turns out that in the end it is necessary to write:
"The Node RED process starts, which makes it possible for events to run threads."
Is that right?
There is a single thread in the JavaScript part of the node.js runtime - the event loop.
To talk of multiple threads can lead to misunderstanding an important core principle of node.js - or at least how Node-RED runs on top of node.js.
When Node-RED starts the flows, the nodes are able to schedule events on the event loop. That is how multiple pieces of work can happen at the "same" time - even if strictly speaking only one thing happens at any one time.
Deeper inside the node.js runtime, pieces of work such as network access or filesystem access may be happening in separate threads, but they will ultimately result in an event being scheduled back on the single node.js event loop thread.
Given your information, it may be more correct to formulate it like this:
"The Code RED process starts, which makes it possible for events (nodes) to run threads that are Editor elements together with this nodes."
No. There are not multiple threads. It is just wrong to say otherwise.
When Node-RED starts it does two things. First it starts an http server that serves up the editor, along with an http API used by the editor to load and modify the running flows. Second, the runtime 'runs' the current flow configuration by instantiating all of the nodes in the flow. This all happens within the single thread of the node.js event loop, as described in the link I shared in my last response
Excuse me. My level of knowledge does not allow me to assert anything. And even more so to argue.
I'm just trying to understand your phrase "flows are also started".
As a regular user, I use the terms node and Node RED thread, which I see in the editor. I'll learn the rest from you.
And that's why I don't understand what it means to run threads in the Editor.