Skip to content
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

try fix some deadlocks #1527

Closed
wants to merge 47 commits into from
Closed

try fix some deadlocks #1527

wants to merge 47 commits into from

Conversation

SimonCropp
Copy link
Contributor

@SimonCropp SimonCropp commented Jan 2, 2023

help to contribute to #1284.

@Evangelink
Copy link
Member

FYI this will help to contribute to #1284.

@SimonCropp
Copy link
Contributor Author

@Evangelink is there a way to update the api test result to match the api changes?

@SimonCropp
Copy link
Contributor Author

@Evangelink ok this is ready for a review

Copy link
Member

@Evangelink Evangelink left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First pass LGTM.

I will need to review the changes to public API to see if it's used on GitHub, and I also want to have a more in-depth look at some of the semaphore changes.

Side question, do you have any example of scenario where you hit the deadlock? Just trying to see if we could improve our tests (which isn't great at the moment).

@SimonCropp
Copy link
Contributor Author

Side question, do you have any example of scenario where you hit the deadlock? Just trying to see if we could improve our tests (which isn't great at the moment).

a consumer of Verify.MsTest hit it here VerifyTests/Verify#751 and my guess was it is related to MSTests use of getawaiter, but i cant be sure.

So no i dont think i could produce a test which would reliably reproduce a deadlock

Copy link
Member

@Evangelink Evangelink left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I implemented a small test framework to test mstest and it does not (yet) support async methods so all the test methods you changed to async are now ignored.

Also, could you please rebase on main one more time (there were a few un-changed parts).

src/Adapter/MSTest.TestAdapter/Execution/TestClassInfo.cs Outdated Show resolved Hide resolved
@@ -41,8 +42,8 @@ public TestMethodAttribute(string? displayName)
/// <param name="testMethod">The test method to execute.</param>
/// <returns>An array of TestResult objects that represent the outcome(s) of the test.</returns>
/// <remarks>Extensions can override this method to customize running a TestMethod.</remarks>
public virtual TestResult[] Execute(ITestMethod testMethod)
public virtual async Task<TestResult[]> Execute(ITestMethod testMethod)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I need to think about this one, as far as I can see it's quite often overridden. I am not sure if that's better to break or offer the two methods Execute and ExecuteAsync and obsolete the former.

@@ -57,7 +58,7 @@ public interface ITestMethod
/// <remarks>
/// This call handles asynchronous test methods as well.
/// </remarks>
TestResult Invoke(object[]? arguments);
Task<TestResult> Invoke(object[]? arguments);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same remark here, it's also used in a few places.

@@ -21,7 +23,7 @@ namespace Microsoft.VisualStudio.TestPlatform.MSTest.TestAdapter.Execution;
/// </summary>
public class TestClassInfo
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I can see on GitHub and internal repo this is not used outside of MSTest so changes to public API are fine (I will do a follow-up PR changing accessibility where possible to reduce un-needed/wanted public surface).

@@ -320,36 +313,33 @@ private void ExecuteTestsInSource(IEnumerable<TestCase> tests, IRunContext? runC

for (int i = 0; i < parallelWorkers; i++)
{
tasks.Add(_taskFactory(() =>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I need to look more into this part because it's changing the logic (I am not sure if that's good or not).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah given i cant compile (and hence cant run locally) i was guessing as to the correct new code.

happy to take direction from you

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably better to keep the old behaviour in here, we are missing tests to be 100% sure of what was the real intent here.

@SimonCropp
Copy link
Contributor Author

rebased

@Evangelink
Copy link
Member

@SimonCropp I am curious as to what issues you are facing with building, would you mind sharing the errors?

@Evangelink
Copy link
Member

@SimonCropp I am starting to think it's probably better to go full breaking change for v4. It's likely to break users extending MSTest but it feels like lots of extra work and increased likelihood of deadlock to keep the GetAwaiter option.

@SimonCropp SimonCropp closed this by deleting the head repository Jun 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants