Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Testhost sharing between discovery & execution #2687
Testhost sharing between discovery & execution #2687
Changes from 28 commits
cad90d0
859965e
30775f1
b9057db
bd267b7
03c5c96
80059ae
809d6f4
b831d87
8ebaabc
ff8507b
629f20f
f91228e
3c2e26b
ef039a2
38df898
55118ac
3e43177
b3953b0
58fd909
0c533f5
90170c5
6328248
73fe5d0
7a89d9a
9cfd6bf
4b246a8
a64fd37
b80b578
02d6205
6e75cfc
393fb3e
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
why can this happen? also, if the user doesn't request a discovery, this will deadlock. should this be a concern?
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.
I'm not sure this (i.e. not issuing a discovery/run request) would cause a literal deadlock, rather indefinite waiting, which shouldn't be that bad given that calling
Abort
with nothing to actually abort is not really encouraged.The need for introducing synchronization here is owed to the fact that the
ProxyOperationManager
is not necessarily initialized when the object is created. True, that's the case when we don't use test sessions, but with test sessions theProxyOperationManager
is only initialized when a discovery/run request is issued, making an abort before even running discovery to crash. Of course, we can do some null checking and haveAbort
do nothing if the proxy is not initialized yet, but in this way at least there's visible consequences to this behavior and maybe that can direct the caller to fix it rather than just ignore the abort request on TP side.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.
that is somewhat concerning. I could imagine writing code:
where if cancellation occurs I might not trigger a discover/tests call, but will have registered an abort handler.
in general that's the result of the existing sync API because Discover/Run blocks the caller's thread. as a result we register a cancellation token handler before calling Discover/Run methods. this means that it would be possible for TP to receive an Abort call before a Discover/Run calls
if TP would take a cancellation token or send an event that a Discovery/Run became abortable, we could ensure to never call Abort before Discover/Run
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.
I think it's best to keep it simple and replace the
ManualResetEvent
with null checks then.