The ScriptAPI will always run in the main thread for SFD's update logic to prevent other issues such as racing conditions, deadlocks, crashes, apphangs and other problems related to "unsafe" threading when manipulating the game world in SFD. The Script also runs in a sandbox environment in another AppDomain to limit the user to prevent harmful code such as System.IO calls - this also makes the code run slower.
theoretically racing conditions and deadlocks are problem of who writes the script if something is not in sync or there are multiple variable assignment without an order. There wouldn't be a problem if (like you said for the while cycle) is defined a time slice for possible deadlocks, also the script sandbox would parse the code one time entirely and not when it is executed.
You could redesign your code so it process a few iterations on your pathfinding logic before "pausing" and wait for the next update cycle and process a few more iterations.
so it needs to be completed in a couple of cycles?
Currently the pathfinding build the entire path and terminates, every second since the enemy is spawned the function is invoked but works only if the new goal node is changed, after a bit of enemy istances the pathfinding is always in execution, one time for enemy3 another for the enemy7 and more the path is complex more the while cycle make the thread hangs costantly for a few milliseconds.
The path can be reused but if some enemies are pointing another player there will be different path calculation.
eventually I want to ask if the CPU AI of the classic SuperFighters was divided in threads (probably yes because of lack of third party programmers).
I know this could be off topic, I will open another in case the discussion continues.