HomeUser Control Panel (unavailable in archive)ForumsTutorialsArt GalleryResourcesMaps

ExecuteFunc unpredictable thread results?

06-15-2005, 04:56 AM#1
Squashy
I know that ExecuteFunc creates another thread (or so I've heard). Therefore, I shouldn't use waits within a function that might be called by ExecuteFunc because it could interfere with the main thread.

I want ExecuteFunc("Foo") to give me the same results as if I normally called function Foo. Can I assume that it will - as long as I don't use waits within function Foo? From my own tests, it appears that I can assume this. But I can't be sure I've covered all of the bases.

Here is a specific example:

Say I have this set of code, which I will designate CODE ONE:

Code:
global integer a
global integer b

function sad takes nothing returns nothing
  ... some time consuming process, however, NO waits are involved. a and b  are NOT affected by the process ...
  set a = 1
  set b = 2
endfunction

function happy takes nothing returns nothing
  set a = 2 
  set b = 1

  call ExecuteFunc("sad")

  if a > b then // IMPORTANT IF STATEMENT
    ... do something important ...
  endif
  
endfunction





Now, say I have this set of code, which I will designate CODE TWO:

Code:
global integer a
global integer b

function sad takes nothing returns nothing
  ... some time consuming process, however, NO waits are involved. a and b  are NOT affected by the process ...
  set a = 1
  set b = 2
endfunction

function happy takes nothing returns nothing
  set a = 2 
  set b = 1

  call sad()

  if a > b then // IMPORTANT IF STATEMENT
    ... do something important ...
  endif
  
endfunction


My question: Will CODE ONE evaluate the "IMPORTANT IF STATEMENT" the exact same way as CODE TWO? Or could the evaluations be different?
06-15-2005, 07:02 PM#2
PitzerMike
The two versions will act differently because ExecuteFunc will wait for the parent thread to reach its end or a wait until the child thread gets control whereas a normal call will be executed before the rest of the calling function.

You can however dispatch a new child thread using a trigger and TriggerExecute which will immediately give control to the child thread and then resume the parent thread and act exactly like a normal call (provided the child function doesn't contain waits).
06-16-2005, 10:20 PM#3
Vexorian
[quote]Therefore, I shouldn't use waits within a function that might be called by ExecuteFunc because it could interfere with the main thread[/code]

Quite the opposite

Quote:
The two versions will act differently because ExecuteFunc will wait for the parent thread to reach its end or a wait until the child thread gets control whereas a normal call will be executed before the rest of the calling function.

You can however dispatch a new child thread using a trigger and TriggerExecute which will immediately give control to the child thread and then resume the parent thread and act exactly like a normal call (provided the child function doesn't contain waits).
No, they will act the same, and using Triggers would give the same results as ExecuteFunc but you will have to clean the action and the trigger to avoid leaks.

Quote:
because ExecuteFunc will wait for the parent thread to reach its end or a wait until the child thread gets control whereas a normal call will be executed before the rest of the calling function.
ExecuteFunc doesn't do that. The only thing that does that is a timer that expires on 0 seconds