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

Question: why _RunTaskContinuations is run on the ambient scheduler from _CancelAndRunContinuations #1595

Open
parkske opened this issue Mar 12, 2021 · 1 comment

Comments

@parkske
Copy link

parkske commented Mar 12, 2021

Is there a specific reason why _RunTaskContinuations is run on the ambient scheduler (via _ScheduleFuncWithAutoInline) when a task has been canceled instead of directly on the running thread's scheduler (may not be the ambient scheduler)?

_ScheduleFuncWithAutoInline([=]() { _RunTaskContinuations(); }, details::_DefaultAutoInline);

@Craig-Proctor
Copy link

From the discussions on Codeplex

Problem/Bug in pplx?
Hello,

I am using pplx on Windows and Linux.

To enforce explicit use of schedulers, I call set_ambient_scheduler(MyInvalidScheduler()) at the beginning of my program. This way I catch the cases where somebody did not explicitly provide a scheduler.

Now something curious can happen. First I create a task with a specific scheduler, then - before the task is actually executed - I chain a continuation to it. Next the task will execute and throw an exception. This will then go through a bunch of functions within ppl (for an exact stack trace see below - with direct links to source here on codeplex). Ultimately _RunTask will do
get_ambient_scheduler()->schedule(_Proc, _Parameter);
This strikes me as odd, as pplx is not using my provided schedulers and instead relies on the ambient scheduler for certain things. Since my ambient scheduler is invalid (see above), things break.

Since I couldn't believe pplx has to rely on the ambient scheduler, I looked at the corresponding code in the PPL. I ended up at pplconcrt.h where the line in _RunTask reads
_CurrentScheduler::_ScheduleTask(_Proc, _Parameter);
So there it explicitly uses the CurrentScheduler and not some ambient scheduler out of the blue.

So my final questions :
Is the ambient scheduler just some nice default when creating tasks or is it inherently needed to make pplx work at all?
Is this a "not implemented" thing in PPLX compared to PPL because there's no ConcRT in PPLX that provides _CurrentScheduler?
What can I do to prevent pplx using schedulers I do not want it to use? -- I guess one way would be to have my schedulers set a thread-local "currentScheduler" variable and then in my InvalidScheduler use this one to figure out the currentScheduler and instead forward to that one?
Detailed stack trace with direct links to code in question:

_CancelAndRunContinuations
_ScheduleFuncWithAutoInline
_RunTask


Thank you very much,
-Matthias
Thread #645412 | Message #1445682 | 2015-09-24
Addendum:

I've hacked pplx so that _ScheduleFuncWithAutoInline and _RunTask take a scheduler_ptr now. In the two places that call _ScheduleFuncWithAutoInline I pass _M_TaskCollection._GetScheduler(). This way I don't need no ambient scheduler anymore.

Does this sound OK or is there some problem I didn't see?

If I create a pull request for a change like this, do I have any chances of getting it accepted?
Thread #645412 | Message #1445711 | 2015-09-24
This does sound like a bug; the ambient scheduler should not be required.

Great work tracking this down. I think your fix sounds reasonable, so please do submit a pull request.

Note: you'll also need to sign our contributor agreement. Take a look at https://casablanca.codeplex.com/wikipage?title=Make%20a%20contribution&referringTitle=Documentation for more.
Thread #645412 | Message #1445790 | 2015-09-24

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

No branches or pull requests

2 participants