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
Right now, the #[scenario] macro only works on functions which take no arguments and return no values.
#[scenario]asyncfnscenario_a(){}
Allowing the user to use a function which takes in arguments is useful for a variety of reasons, with the most important being adding context to the scenario. The tricky part of this is that (1) Scenarios are run in parallel on one machine, and (2) Scenarios can be sent between machines. This likely limits the arguments allowed for a scenario to be (a) references/Copy and (b) serializable. Having arguments which are Clone is a possibility (and just cloning on every invocation), though I worry it will lead to a performance trap which is easy to fall into.
For context, I've been looking at how WebServers do n-arity handlers (eg. How axum handlers work), however as far as I can tell they require a boxed future which isn't ideal. Another option I've been considering is expanding the #[scenario] macro to essentially provide a "wrapper" function around the user-supplied scenario which would take some Argument object and expand it into the user's arguments.
Essentially, there are two intertwined sets of requirements: (1) How to handle the type-system tricks for being generic over any n-arity function, (2) How to handle the cloning/referencing and serialization/deserialization of the arguments for running a function in parallel + sending data across servers.
The text was updated successfully, but these errors were encountered:
Right now, the
#[scenario]
macro only works on functions which take no arguments and return no values.Allowing the user to use a function which takes in arguments is useful for a variety of reasons, with the most important being adding context to the scenario. The tricky part of this is that (1) Scenarios are run in parallel on one machine, and (2) Scenarios can be sent between machines. This likely limits the arguments allowed for a scenario to be (a) references/Copy and (b) serializable. Having arguments which are
Clone
is a possibility (and just cloning on every invocation), though I worry it will lead to a performance trap which is easy to fall into.For context, I've been looking at how WebServers do n-arity handlers (eg. How axum handlers work), however as far as I can tell they require a boxed future which isn't ideal. Another option I've been considering is expanding the
#[scenario]
macro to essentially provide a "wrapper" function around the user-supplied scenario which would take someArgument
object and expand it into the user's arguments.Essentially, there are two intertwined sets of requirements: (1) How to handle the type-system tricks for being generic over any n-arity function, (2) How to handle the cloning/referencing and serialization/deserialization of the arguments for running a function in parallel + sending data across servers.
The text was updated successfully, but these errors were encountered: