Just send a message to flow 2 then. You can have multiple wires coming from single node, so you can send one message off to flow 2 (via a Link Out node if it is on a different tab) and meanwhile carry on with flow 1. However, all those messages will go to the one and only instance of flow 2. What is it that is in flow2 that would allow parallel processing?
My understanding is that a flow, when it is called multiple time, will run multi-threaded.
So if my loop call it 7 times, 7 instance of that flow would run in parallel instead of the same flow running 7 times sequentially.
My loop calls a flow that take a file an convert it to something else. If my loop, loops 7 times and the conversion takes 2 minutes , I don't want the whole thing to take 14 minutes but 2 minutes, or close too.
You don't call a flow, you pass it a message. Arguably the Link Call sequence can be thought of a 'calling' but actually you send it a message and then when it is done it sends one back.
However, you can have multiple messages flowing through a sequence of nodes (a flow) at once if that is what you mean. So if you have a flow that reads a file, processes it, and writes another file, and you send it two messages one after the other then the File node will read one file and pass it on the processing nodes. Then it will immediately start reading the next file (which is done in a different process in the OS) and while it is reading it the processing may proceed. If the processing is processor intensive, however, then it can only process one at a time, unless you pass the processing off to multiple separate processes outside node-red.
Sorry, there seem to be a lot of instances of the word 'process' and its derivatives in those sentences, but hopefully you get what I am meaning.
A flow is a collection of nodes organized as a linked list.
Each node is instantiated exactly once.
You may use (the functionality provided by) a node more than once in a flow (like all of us do e.g. with the debug node). Each time, you drop its representation in the editor, a new instance of it is created - so we're back at the second bullet point.
I'm not quite sure what you reference as "the loop" ... but: Sending messages is always Fire & Forget. A node receives a message, does his job (occasionally multi-threaded!) and then emits the result of his doing as a message. If there's still job left to be done, the node continues his doing ... until he assumes things are settled. There's no feedback to the node if his message was received...