IntegrationTest: Let RandomKill and SyncChurn run in sequence #4588
Conversation
eval-exec
force-pushed
the
exec/sequence-ci
branch
2 times, most recently
from
a001c84 to
439ed15
Compare
Signed-off-by: Eval EXEC <[email protected]>
eval-exec
force-pushed
the
exec/sequence-ci
branch
from
439ed15 to
b3553e7
Compare
| while worker_running > 0 { | ||
| if max_time > 0 && start_time.elapsed().as_secs() > max_time { | ||
| // shutdown, specs running to long | ||
| workers.shutdown(); | ||
| break; | ||
| } | ||
|
|
||
| if worker_running == 1 && !started_sequential { |
There was a problem hiding this comment.
This seems the last spec job may still have overlapping with the sequential spec job, suppose the msg is Notify::Start, means last job is starting executing, and we start workers.start_sequencial(), one sequential job will start, so there is a overlapping.
There was a problem hiding this comment.
add a check && msg != Notify::Start ?
means the last job has just finished.
There was a problem hiding this comment.
This seems the last spec job may still have overlapping with the sequential spec job, suppose the
msgisNotify::Start, means last job is starting executing, and we startworkers.start_sequencial(), one sequential job will start, so there is a overlapping.
workers.start_sequencial() will only be executed once.
After executing workers.start_sequencial(), the started_sequential variable will be true.
There was a problem hiding this comment.
I know it will be executed once, I mean when worker_running == 1 && !started_sequential is true, msg maybe Notify::Start, the last spec job is starting to run, not mean the last job has just finished, if we start sequential job at this time, there maybe a overlapping with last job?
There was a problem hiding this comment.
seems it's ok, workers.start_sequencial() only set a flag.
There was a problem hiding this comment.
When worker_running == 1, only one worker (the sequential worker) should be running, and all other parallel workers should have exited.
msgcould beNotify::Start
If msg is Notify::Start, the sequential worker might be executing self.run_spec(spec.as_ref(), 0); at that moment.
A worker can execute only one spec at a time.
Therefore, there is no chance of overlap.
There was a problem hiding this comment.
the last running worker must be the sequencial_worker...
What problem does this PR solve?
Related changes
Check List
Tests
Side effects
Release note