BP runs in main game thread same that you got in C++, when you call blueprint event it will pass the thread to VM and execute blueprint code with it until function (events counts as functions) in blueprint is ended, majority of nodes are also C++ bindings so blueprint VM simply calls C++ functions. Yes, that means when you would infinitly loop blueprint you would freeze entire engine, but VM has protection for that and stops execution if it detects long loops.
Order of execution depends on implementation of perticilar event how it is binded to blueprint, In case of Init in GameInstance it is renamed implementable event
/** Opportunity for blueprints to handle the game instance being initialized. */
UFUNCTION(BlueprintImplementableEvent, meta=(DisplayName = "Init"))
void ReceiveInit();
Called at begining of UGameInstance:Init()
void UGameInstance::Init()
{
ReceiveInit();
if (!IsRunningCommandlet())
{
UClass* SpawnClass = GetOnlineSessionClass();
OnlineSession = NewObject<UOnlineSession>(this, SpawnClass);
if (OnlineSession)
....
So technically when you call Super::Init()
Delay node use system called Latent Action, clock icon on node indicates that, it’s a special “Wait For” event system where you make class that tracks specific action (in case f delay it checks time passed) where VM binds to it and being checked on every tick (engine loop) if conditions are meet, if they are, it will execute binded function (in case of blueprint it will exec pin on the node). Yo can see how they are made here:
So paralism here is just a illusion kind of like in JavaScript (Node JS aspecially), CPU is so fast that some delay system may look like it’s run in parallel where in reality it just being binded to system that tracks on every specific occasion if conditions for execution are meet. Same goes with timer system in UE4.