Looking back over this, it looks like "threads" don't share the same data space? So they're really more like processes? (In the linux sense).
Still, I don't quite understand why:
Call foo, store results in bah, run in a thread
wait until info exists local bah
Doesn't work, while making it a global does.
Cool. I was close; I just didn't get my analyze quite right.
I should add that, for safety, the global variable name should either be really, really unique (probably not "s1"), or there needs to be an "eval gunset s1" in front of the step that stores the response in s1.
What's the chance of this not completing, due to the increment code being non-atomic?
thread 1: gget all_finished
thread 2: gget all_finished
thread 1: incr
thread 2: incr
thread 1: gset all_finished
thread 2: gest all_finished
==> all_finished never reaches $length
In SVT, you could wait for "prev in session analyzed". This doesn't seem to be in iTest?
There really ought to be the ability to wait for a thread or all threads.
There is multithreading support available in iTest. It is upto the user to enable it. For each step, if you open the step properties, the General properties have a checkbox for "Start the step (in a new thread) and proceed to the next step".
Notice that when user enables this option, there is a purple arrow that appears next to this step.
This means that if this property was enabled for step 3 in the test case, then during execution, after iTest completes step 2, step 3 will be launched in a new thread and the execution will immediately proceed to step 4.
Main thread New thread
* Step 1
* Step 2
* Step 4 * Step3 <-- New thread created here
* Step 5 |
No one has followed this question yet.