这是关于C ++ REST SDK的异步任务功能的概念性问题（也许还有些菜鸟问题）。
在一个基本应用程序中，我有一个客户端并执行多个请求，例如
http_client client(U("whatever"));
for(int i=0; i<100; ++i)
{
http_request request;
//fill the request
client.request(request).then([](http_response response) { /* do something*/});
}
（foor循环只是指示该请求经常发送，我的代码中并未真正使用它）。
问题：
据我了解，异步任务库然后以并行方式处理这些传入请求-意味着不是主线程以类似事件的方式处理所有任务，而是该库以某种方式将任务分配给基础线程池（-对我来说不透明-）方式。我说对了吗？
如果以前的视图是正确的，则有任何理由将REST SDK与C ++的多线程功能结合在一起。例如，再次执行上述循环，启动10个线程，然后在每个进程中进行10次循环迭代。这有意义还是不必要？
而且，总的来说，是否有任何常见的模式应通过C ++ 11多线程功能组合ppl功能？还是可靠地依靠REST SDK和ppl更好地完成工作？
（信息：我也在cpprest讨论页面上也问过这个问题。但是，这个论坛似乎不再保持。）
据我了解，异步任务库然后以并行方式处理这些传入请求-意味着不是主线程以类似事件的方式处理所有任务，而是该库以某种方式将任务分配给基础线程池（-对我来说不透明-）方式。我说对了吗？
是的，在REST SDK中，他们使用线程池启动任务继续。在Windows上，它们使用Windows API函数的ThreadPool（ CreateThreadPool，TrySubmitThreadpoolCallback等等）。在Linux上，他们使用Boost 1。
如果以前的视图是正确的，则有任何理由将REST SDK与C ++的多线程功能结合在一起。例如，再次执行上述循环，启动10个线程，然后在每个进程中进行10次循环迭代。这有意义还是不必要？
该平台完全不需要，它有自己的线程池。
而且，总的来说，是否有任何常见的模式应通过C ++ 11多线程功能组合ppl功能？还是可靠地依靠REST SDK和ppl更好地完成工作？
好吧，a的整个想法task是抽象化线程的使用。处理许多并行任务时，线程的伸缩性不好。传统方法是使用线程池不为每个新任务生成新线程。
ppl任务使您能够以更优雅的方式处理异步IO。您可以将CPU绑定的任务封装在中ppl::task，在这些任务中，您可以生成另一个异步IO操作，并ppl::task::then在异步IO完成后用于继续执行CPU绑定的任务。
该机制是一个task-> aync IO -> continuation task-> async IO ->task这样的链。当任务启动IO操作时，基础线程池将移至下一个任务。当异步IO完成时，它将继续任务在线程池任务队列的末尾排队。
因此，不，您不应该自己直接创建任何对象std::thread。但是，您确实希望使用同步对象，例如，std::mutex 如果您的任务访问任何读取资源。
------------------------------------
一个不错的好处：
在Visual Studio 2015 RTM及更高版本的VC ++上，您可以await在任务上使用并摆脱then：
http_client client(U("whatever"));
for(int i=0; i<100; ++i)
{
http_request request;
//fill the request
auto response = await client.request(request);
//do something with the response
}
-------------------------------------------------- -
不好的收获：
根据我对REST SDK的经验，它的性能非常差，而不是C ++平台所期望的。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句