Hello Heikki,
>> [...]
>> So threadRun() would not have the opportunity to stop the scheduled
>> transaction, even if beyond the end of run, because it would not have got
>> out of doCustom, in the case I outlined above.
>
> I see. Instead of moving to FINISHED state, then, we could stay in THROTTLE
> state, and 'return' out of doCustom(), to give the code in threadRun() a
> chance to detect that the timer is up. Something like the attached. (I moved
> the check after the check for latency_limit, because that code updates
> txn_scheduled. Seems more like a more correct place, although that's as a
> separate issue.)
Although I think it would works, I do not find it better than the previous
situation: Before the change throttling simply jumps to finished if time
is up, while with that option the jump cannot be seen from within doCustom
and relies on threadRun to do so, which is somehow much harder to see from
the code because things happen in two functions.
I would rather move state changes from threadRun to doCustom only, so that
they are all in one place where it is easier to check and understand.
As a PoC, see attached which does that and also records all stats instead
of trying to be clever, and tries to homogeneise comments somehow. As I
find it strange that a script can be interrupted in sleep and after a
shell command, but not in other states, rather documents that once it
started it will run to its end, and only cut it out before or after, but
not within. Also, there are no state changes outside doCustom, and
threadRun only looks at the states for decisions.
--
Fabien.
