I'm noticing an issue with pplx::details::do_while.
It appears that any long operation that gets rapidly scheduled will create a very long task chain. This consumes a large amount of memory (certainly in our application). Is this a known issue? Do you have a work around? It appears its due to the then clause in the do_while.
If the func call returns a pplx::task_from_result that contains a conditional based on the work done in the function, the then will schedule instantly. It appears that the original task does not get torn down until the continuations complete from the func returning a task<false>. This creates a large chain of tasks.
Any help would be appreciated.
Comments: Yes, the behavior you mentioned is expected, and it is caused by the nature of "ppl task unwrapping" . Please do not directly use do_while anywhere in your code as it's under details namespace. For a better do_while implementation, please look at the create_iterative_task function in ppl powerpack project http://pplpp.codeplex.com/ . That implementation will not suffer from this issue. Hong
It appears that any long operation that gets rapidly scheduled will create a very long task chain. This consumes a large amount of memory (certainly in our application). Is this a known issue? Do you have a work around? It appears its due to the then clause in the do_while.
If the func call returns a pplx::task_from_result that contains a conditional based on the work done in the function, the then will schedule instantly. It appears that the original task does not get torn down until the continuations complete from the func returning a task<false>. This creates a large chain of tasks.
Any help would be appreciated.
Comments: Yes, the behavior you mentioned is expected, and it is caused by the nature of "ppl task unwrapping" . Please do not directly use do_while anywhere in your code as it's under details namespace. For a better do_while implementation, please look at the create_iterative_task function in ppl powerpack project http://pplpp.codeplex.com/ . That implementation will not suffer from this issue. Hong