You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we store validation functions as Actor inside ExecutionScenario etc., but Actor contains additional information about the operation, defined by user, and logically has fewer limitations:
An actor can throw exceptions, while a validation function can't
An actor can have arguments
Fields cancelOnSuspension, allowExtraSuspension, blocking, causesBlocking, promptCancellation, isSuspendable of the Actor class makes no sense in case of a validation function.
The only reason for doing this is that it's easier to use TestThreadExecutionGenerator, which has TestThreadExecution create(Runner runner, int iThread, List<Actor> actors,... method.
We can fix it in two ways:
To create a hierarchy like that: In that case, we can move to the interface all required fields for execution generation and easily pass a validation function or an actor in into TestThreadExecutionGenerator. But, for example, property isSuspendable always will return false in case of validation function, so it looks weird and redundant, especially because it is needed only for one place in code.
To create wrappers with all required properties for a validation function method and an actor to pass into the TestThreadExecutionGenerator. This approach requires minimum code changes and development time but leads to some amount of small object allocations (for wrappers). We need to measure whether this results in decreased performance.
To refactor TestThreadExecutionGenerator to make it able to create executions for validation methods too.
The text was updated successfully, but these errors were encountered:
I think we eventually should refactor TestThreadExecutionGenerator. See, e.g. this issue #196
Let's collect all the problems with current implementation that we want to solve with the refactoring.
Currently, we store validation functions as
Actor
insideExecutionScenario
etc., butActor
contains additional information about the operation, defined by user, and logically has fewer limitations:cancelOnSuspension
,allowExtraSuspension
,blocking
,causesBlocking
,promptCancellation
,isSuspendable
of theActor
class makes no sense in case of a validation function.The only reason for doing this is that it's easier to use
TestThreadExecutionGenerator
, which hasTestThreadExecution create(Runner runner, int iThread, List<Actor> actors,...
method.We can fix it in two ways:
In that case, we can move to the interface all required fields for execution generation and easily pass a validation function or an actor in into
TestThreadExecutionGenerator
. But, for example, propertyisSuspendable
always will returnfalse
in case of validation function, so it looks weird and redundant, especially because it is needed only for one place in code.TestThreadExecutionGenerator
. This approach requires minimum code changes and development time but leads to some amount of small object allocations (for wrappers). We need to measure whether this results in decreased performance.TestThreadExecutionGenerator
to make it able to create executions for validation methods too.The text was updated successfully, but these errors were encountered: