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

Investigate ppltasks dependency for vNext #3606

Open
StephanTLavavej opened this issue Mar 31, 2023 · 2 comments
Open

Investigate ppltasks dependency for vNext #3606

StephanTLavavej opened this issue Mar 31, 2023 · 2 comments
Labels
vNext Breaks binary compatibility

Comments

@StephanTLavavej
Copy link
Member

I'm going to need to revert #2654 and #3255, so here are vNext todos that were mentioned in the latter PR's added comment:

When we can break ABI, we should:

  • In <ppltasks.h>, reconsider whether _Task_impl_base::_Wait() should throw invalid_operation; it's questionable whether that's conforming, and if users want to block their UI threads, we should let them.
  • Investigate whether we can avoid the ppltasks dependency entirely, making all of these issues irrelevant.
@AlexGuteniev
Copy link
Contributor

  • Investigate whether we can avoid the ppltasks dependency entirely, making all of these issues irrelevant.

I think that <ppltasks.h> is only used to support asynchronous (non-deferred) std::async, to spawn separate workers.

Instead of using <ppltasks.h> for that, we should use thread pool directly, like we currently do in <execution> / parallel_algorithms.cpp.

@AlexGuteniev
Copy link
Contributor

Related #2206 (comment)

<future> includes <ppltasks.h> and thus drags a bunch of (more than 60) non-Standard non-reserved identifiers in.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
vNext Breaks binary compatibility
Projects
None yet
Development

No branches or pull requests

2 participants