Call or Spawn

[Dekade 2]

I'm a bit confused about 'Call' and 'Spawn'.

 

In which case would you use one over the other?

[dreadedentity 278]

I keep erasing what I typed because I'm not happy with how it's starting out. Maybe if I just list the pros/cons of either you'll get it:

 

call (Unscheduled environment)

• Blocks the thread until the code completes
• Can return values easily
• Can easily destroy FPS
• However, they can't slow each other down like too many spawns can
• Cannot use sleep/waitUntil

 

spawn (scheduled environment)

• Does not block the thread (code keeps going and spawned code essentially splits off and executes)
• Can't return values/need workarounds to return values
• All spawned code gets 3ms to run per frame, can't affect FPS
• However if there are too many spawns with too much processing, logically it will take all of them longer to run because they have to wait for their turn
• Can use commands like sleep, waitUntil
• Can convert an unscheduled environment to a scheduled environment

 

To reiterate the point directly above, scheduled environments "pass along" their scheduled-ness to lower scopes. Essentially, you can turn any environment into a scheduled environment

However, a scheduled environment can never "turn into" an unscheduled environment (in the same way):

//inside init.sqf (a scheduled enviornment)
example = {
	sleep 1;
	hint "this is not an unscheduled enviornment";
};
call example;

 

[dwringer 45]

31 minutes ago, dreadedentity said:

a scheduled environment can never "turn into" a scheduled environment 

I believe you meant to say a scheduled environment can never "turn into" an unscheduled environment.

The way I'd say it is that "call" will always block until a result is returned (and can't sleep/wait), but if you use "spawn" your code will go off into a new thread where you are free to sleep, wait, "call" other things, whatever.

One is also free to use "spawn" inside of a "call". But the call will return without any guarantee that the spawned code finished.

At the end of the day, when you use "call" the return value you get will be the result of the called code.  If you use "spawn" then the return value will be immediate, and it will be a script handle identifying the spawned thread which will go on running in parallel with the code in the context that called it.

[dreadedentity 278]

5 minutes ago, dwringer said:

I believe you meant to say a scheduled environment can never "turn into" an unscheduled environment.

Good catch, I fixed it in my post

[Dekade 2]

Thanks guys! I got a better understanding of Call and Spawn now.

[pierremgi 4910]

On 4/9/2022 at 4:25 AM, dreadedentity said:

However, a scheduled environment can never "turn into" an unscheduled environment (in the same way):

 

 

Not exactly. You can script an isNil {code} for a unscheduled code from a scheduled one. That helped me for displaying elaborated dynamic texts in an heavy scheduled environment. Without that, the texts/pictures were not always displayed, depending on scheduler load.

 

just test:

[] spawn {
  sleep 3;
  hint str canSuspend;
 isNil {systemChat str canSuspend};
};

 

[dreadedentity 278]

I guess it depends on what "same" means to you, but I did put "(in the same way)" at the end

[sarogahtyp 1109]

The most important biki page for understanding the different environments is this one:

 

https://community.bistudio.com/wiki/Scheduler

 

It was linked already by @dreadedentity but I would like to explicitly recommend reading this page for a better understanding.

[sarogahtyp 1109]

the only thing what runs unscheduled in ur examples is the content of the isNil command. everything else runs scheduled.