Skip to content

Add DelayedConstraint in NetStandard 1.6 build #2010

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

Merged
merged 1 commit into from
Feb 26, 2017
Merged

Conversation

ChrisMaddock
Copy link
Member

@rprouse - this is related to our discussion on #1638. I'd already done this as feasibility check, so thought it made sense to push it, and continue the discussion as to if we actually want to use it or not here - I'm not worried if we close instead. 😄

This re-enables DelayedConstraint in the netstandard build. It includes the System.Threading.Thread package - so I also tidied up a few places where Thread.Sleep() had been excluded, as that's now available.

This doesn't tackle timeout's, as I don't think Thread.Abort() is available in netstandard - notes on that are in #1638.

@ChrisMaddock ChrisMaddock added this to the 3.7 milestone Jan 27, 2017
@ChrisMaddock ChrisMaddock self-assigned this Jan 27, 2017
return _runComplete.WaitOne(timeout);
#endif
}
Copy link
Member Author

@ChrisMaddock ChrisMaddock Jan 27, 2017

Choose a reason for hiding this comment

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

These two methods do the same thing on all platforms I believe, just Portable and Netstandard don't have the .WaitOne(int, bool) overload. I don't think the conditional is necessary here.

Copy link
Member

Choose a reason for hiding this comment

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

I think the .WaitOne(int, bool) overload was missing from some platforms we no longer support.

Copy link
Member

@CharliePoole CharliePoole left a comment

Choose a reason for hiding this comment

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

This looks great to me. Even though that makes two of us, I think we should get @rprouse 's comments before merging, since this is a fairly important one.

@@ -179,7 +179,7 @@ public static ITestResult ExecuteWorkItem(WorkItem work)
// TODO: Replace with an event - but not while method is static
while (work.State != WorkItemState.Complete)
{
#if PORTABLE || NETSTANDARD1_6
#if PORTABLE
System.Threading.Tasks.Task.Delay(1);
#else
Thread.Sleep(1);
Copy link
Member

Choose a reason for hiding this comment

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

In general, do we think it's better to use Thread.Sleep or Task.Delay where both are available? I'm wondering if we should change this generally in a future PR.

Copy link
Member Author

Choose a reason for hiding this comment

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

I think it might be worth making a decision on the future of PCL, before we decide that. We previously talked about it targeting netstandard 1.0, but I'm not sure if we have much need to target that over netstandard 1.3 - which would allow us to use System.Threading - and then Thread.Sleep() across all platforms.

If we did that - I'd vote for reducing differences between platforms over any minor performance benefit Task.Delay() may give us. 😄

Copy link
Member

Choose a reason for hiding this comment

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

That's fair enough for our framework code itself. For tests, it may be different. I replaced Thread.Sleep with Task.Delay in some of our tests to eliminate spurious failures. My general impression is that Sleep has more of a tendency to go extra long in some circumstances.

Copy link
Contributor

Choose a reason for hiding this comment

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

That impression matches my understanding which is that Delay means "schedule using a precise timer" and Sleep means "I have nothing particularly important to do, deprioritize me."

return _runComplete.WaitOne(timeout);
#endif
}
Copy link
Member

Choose a reason for hiding this comment

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

I think the .WaitOne(int, bool) overload was missing from some platforms we no longer support.

@CharliePoole
Copy link
Member

@ChrisMaddock Shall we go ahead and merge this?

@ChrisMaddock ChrisMaddock merged commit 52e526f into master Feb 26, 2017
@ChrisMaddock
Copy link
Member Author

I think it can be - thanks!

@ChrisMaddock ChrisMaddock deleted the ns-delcon branch February 28, 2017 12:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants