-
Notifications
You must be signed in to change notification settings - Fork 59
Make scenario finalizing more functional #65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
315b0b0
46566a2
8a4fd21
81a345b
7e72ab7
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -109,20 +109,20 @@ You can also launch multiple multi-UA scenarios concurrently using | |
| non-blocking mode: | ||
|
|
||
| ```python | ||
| scens = [] | ||
| finalizers = [] | ||
| for path, scen in pysipp.walk('path/to/scendirs/root/', proxyaddr=('10.10.8.1', 5060)): | ||
| print("Running scenario collected from {}".format(path)) | ||
| scen(block=False) | ||
| scens.append(scen) | ||
| finalizers.append(scen(block=False)) | ||
|
|
||
| # All scenarios should now be running concurrently so we can continue | ||
| # program execution... | ||
| print("Continuing program execution...") | ||
|
|
||
| # Wait to collect all the results | ||
| # Calling `scen` returns a finalizer that can be | ||
| # used to wait for each scenario with a timeout | ||
| print("Finalizing all scenarios and collecting results") | ||
| for scen in scens: | ||
| scen.finalize() | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah not sure what you mean about "breaking the api", you're already doing that with this change afaict.. so you'll have to explain. |
||
| for finalizer in finalizers: | ||
| finalizer(timeout=10) | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think we've talked about it in passing but, we might want to move to an explicit method name here. I'm not against Definitely something for future work though, no need to address here.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. hello, are you talking about the ScenarioType having both
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm talking about 2 things:
Right now you've made things arguably more indirected by returning a closure from
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The user should have access to the finalizer only when
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I like this idea better then returning an anon closure personally. It also would tie multi-script-execution lifetime to the scenario object, and for example if one wants to get the results from the last scenario run you just call
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This solution will change the existing API and be backwards incompatible btw. We are trying to implement a sync interface to an async functionality. We can make the Scenario an awaitable to simplify the interface, but this would require the user to run async tests. Or the Scenario can just be a context manager.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Not if we make
Yes which is why this needs thorough thought and ideally more then just our opinions 😂
This idea i don't mind. If we're going to offer a sync interface it may also make sense to consider spawning trio in another thread and then having the main thread make calls to it with We should eventually be supporting async code for spawning and scenarios especially to support multi-script cases where a user wants to do cmd restarts, cancels, etc. |
||
| ``` | ||
|
|
||
| `scen.finalize()` actually calls a special cleanup function defined in the | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -6,8 +6,9 @@ | |
| import subprocess | ||
| import time | ||
| from . import utils | ||
| from pprint import pformat | ||
| from collections import OrderedDict, namedtuple | ||
| from functools import partial | ||
| from pprint import pformat | ||
|
|
||
| import trio | ||
|
|
||
|
|
@@ -149,18 +150,19 @@ def clear(self): | |
| self._procs.clear() | ||
|
|
||
|
|
||
| async def run_all_agents(runner, agents, timeout=180, block=True): | ||
| async def run_all_agents(runner, agents, timeout, block=True): | ||
| """Run a sequencec of agents using a ``TrioRunner``.""" | ||
|
|
||
| try: | ||
| await runner.run((ua.render() for ua in agents), timeout=timeout) | ||
| if block: | ||
| await finalize(runner, agents, timeout) | ||
| return runner | ||
| return await finalize(runner, agents, timeout) | ||
| else: | ||
| return finalizer(runner, agents) | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, I just don't see how this is beneficial. Instead of returning the runner now we're returning a closure that calls I actually find this somewhat hard to follow and not any more functional then the original method which does this same thing.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What is the benefit of exposing an implementation detail like the runner to the user? The downside is that it leaves more space for the user to misuse the API. |
||
| except TimeoutError as terr: | ||
| # print error logs even when we timeout | ||
| try: | ||
| await finalize(runner, agents, timeout) | ||
| return await finalize(runner, agents, timeout) | ||
| except SIPpFailure as err: | ||
| assert "exit code -9" in str(err) | ||
| raise terr | ||
|
|
@@ -178,3 +180,10 @@ async def finalize(runner, agents, timeout): | |
| raise SIPpFailure(msg) | ||
|
|
||
| return cmds2procs | ||
|
|
||
|
|
||
| def finalizer(runner, agents): | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, I don't see how this gives anything more functional honestly. Instead of a runner (which also defines What's the motivation?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. the API is cleaner and less error prone as the runner is not exposed to the user anymore which means fewer chances of reaching invalid states. Functional as in less object oriented.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Not sure how that's possible to reach invalid states but yeah I guess in theory? If we don't have a runner and only a simple function there there's also no future option for adding cancellation support, which is kinda what
Because we aren't returning a runner? |
||
| def with_timeout(timeout): | ||
| return trio.run(partial(finalize, runner, agents, timeout=timeout)) | ||
|
|
||
| return with_timeout | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yah much better.