In which order are custom python components run on a grasshopper canvas?

Just curious, as i am currently hunting around my spaghetti definition for a python component that forgot to set scriptcontext to ghdoc:

1. What is the order in which python components are executed in a grasshopper definition?

2. I noticed that python code is run one after the other (is that because of GIL or simply lack of multithreading in grasshopper?), while some stuff sticks after the code is completed (scripcontext stuff).

May we know what else stays in the (ephemeral cloud of) python environment? e.g. do variables declared in one python component stay declared and could be called in another component (that would be really hairy to debug)?

I would assume that components sequentially run downstream of the wires, but what about parts where the components diverge and each do their own thing? is there a way to determine the sequence in which components are executed on a canvas? Are they run concurrently as the definition forks and progresses downstream?

Normally it wouldn't matter, but for a newbie pythonist inserting components within a large definition, its quite impossible to tell where, for example, was the python component where i used Rhino.RhinoDoc.ActiveDoc for a while and then forgot to switch it back to ghdoc, causing many other python components to break when i put them together.

Some pointers would be greatly appreciated, or even some good rules of thumb to follow.

regards,

in python's thrall

p.s. sometimes it happens when python code raises an exception halfway through code execution (after switching to Rhino.RhinoDoc.ActiveDoc, before switching back to ghdoc), but i could at least find them as they are coloured red.

p.p.s by the way, if it isn't already, wouldn't it be really powerful if grasshopper2 were to be built with concurrency in mind (as understood in golang)? In a really enlightening youtube video by Rob Pike (https://www.youtube.com/watch?v=cN_DpYBzKso), it seemed to me that his slides about gopher's concurrency model looked very familiar (input, goroutine, output) to how we would use grasshopper.