Le 04/01/2019 à 14:06, Romain Francois a écrit :
> That should be fine indeed. I just don't want the task to start "right now"
> as SerialTaskGroup::AppendReal() seems to be doing.
It would probably be fine to add a DeferredSerialTaskGroup or something.
Regards
Antoine.
That should be fine indeed. I just don't want the task to start "right now" as
SerialTaskGroup::AppendReal() seems to be doing.
> Le 4 janv. 2019 à 13:38, Antoine Pitrou a écrit :
>
>
> Le 04/01/2019 à 12:24, Romain Francois a écrit :
>>
>> I guess that just means I need some way to hold the
Le 04/01/2019 à 12:24, Romain Francois a écrit :
>
> I guess that just means I need some way to hold the tasks before they go in
> the task groups.
You can make the task a lambda function which will capture the necessary
data by value (such as any shared_ptr pointing to the data the task
will
Thanks. I think Task Group suits my needs almost. I might need some extra layer
around it.
Here is my use case. When converting a record batch to an R data structures,
all R allocation has to happen on the main thread, but then filling the vectors
can (for some of them) be done in a task that
Hi Romain,
No, it's better if you use the CPU thread pool directly (or through
TaskGroup, if that suits your execution model better).
Regards
Antoine.
Le 03/01/2019 à 14:29, Romain Francois a écrit :
> Hello,
>
> Are the functions in parallel.h the de facto model for parallelisation in
>
