C ++ 1z контекст потоковой подпрограммы и планирование сопрограмм

Согласно этой последней версии C ++ TS: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4628.pdf, и, основываясь на понимании поддержки языка асинхронной / ожидающей C #, мне интересно, что такое «контекст выполнения» (терминология, заимствованная из C #) сопрограмм C ++?

Мой простой тестовый код в Visual C ++ 2017 RC показывает, что сопрограммы, кажется, всегда выполняются в потоке пула потоков, и разработчику приложения предоставляется небольшой контроль над тем, в каком контексте потока могут быть выполнены сопрограммы — например, Может ли приложение принудительно выполнить все сопрограммы (с созданным компилятором кодом конечного автомата) только в основном потоке, без с участием любого потока пула потоков?

В C # SynchronizationContext — это способ указать «контекст», в котором все «половинки» сопрограммы (код конечного автомата, сгенерированный компилятором) будут размещены и выполнены, как показано в этом сообщении: https://blogs.msdn.microsoft.com/pfxteam/2012/01/20/await-synchronizationcontext-and-console-apps/, в то время как текущая реализация сопрограммы в Visual C ++ 2017 RC, кажется, всегда полагается на среду выполнения параллелизма, которая по умолчанию выполняет сгенерированный код конечного автомата в потоке пула потоков. Существует ли аналогичная концепция контекста синхронизации, которую пользовательское приложение может использовать для привязки выполнения сопрограммы к определенному потоку?

Кроме того, каково текущее поведение сопрограмм по умолчанию для «планировщика», реализованное в Visual C ++ 2017 RC? т.е. 1) как точно указано условие ожидания? и 2) когда условие ожидания выполнено, кто вызывает «нижнюю половину» приостановленной сопрограммы?

Мое (наивное) предположение относительно планирования задач в C # состоит в том, что C # «реализует» условие ожидания исключительно путем продолжения задачи — условие ожидания синтезируется задачей, принадлежащей TaskCompletionSource, и любая логика кода, которая должна ждать, будет связана как продолжение это так, если условие ожидания удовлетворяется, например, если полное сообщение получено от низкоуровневого сетевого обработчика, он выполняет TaskCompletionSource.SetValue, который переводит базовую задачу в завершенное состояние, эффективно позволяя цепочечной логике продолжения начать выполнение (перевод задачи в состояние / список готовности из предыдущее созданное состояние) — в сопрограмме C ++ я предполагаю, что std :: future и std :: обещание будут использоваться в качестве аналогичного механизма (std :: future — это задача, а std :: обещание — это TaskCompletionSource и использование тоже удивительно похожи!) — так ли планировщик сопрограмм C ++, если таковой имеется, полагается на некоторый подобный механизм для выполнения поведения?

[EDIT]: после некоторых дальнейших исследований я смог написать очень простую, но очень мощную абстракцию, называемую awaitable, которая поддерживает однопотоковую и кооперативную многозадачность и имеет простой планировщик на основе thread_local, который может выполнять сопрограммы в потоке корень сопрограмма запущена. Код можно найти в этом репозитории github: https://github.com/llint/Awaitable

Awaitable может быть составлен таким образом, что он поддерживает правильное упорядочение вызовов на вложенных уровнях, и он имеет примитивную выдачу, синхронизированное ожидание и настройку, готовые откуда-то еще, и из этого может быть получен очень сложный шаблон использования (такой как бесконечные циклические сопрограммы, которые только просыпаться, когда происходят определенные события), модель программирования тесно следует шаблону асинхронного / ожидающего выполнения C # Task. Пожалуйста, не стесняйтесь оставлять свои отзывы.

template<class _Ty>
void await_suspend(future<_Ty>& _Fut,
experimental::coroutine_handle<> _ResumeCb)
{   // change to .then when future gets .then
thread _WaitingThread([&_Fut, _ResumeCb]{
_Fut.wait();
_ResumeCb();
});
_WaitingThread.detach();
}