4 ms·
It just uses native go function closure to hold and pass data among tasks, and it requires users to consider the data race problem. Cuz in some cases, tasks are
by noneback 2y ago
It just uses native go function closure to hold and pass data among tasks, and it requires users to consider the data race problem. Cuz in some cases, tasks are executed in parallel.
- atombender 2y agoDo you have an example of this done idiomatically? All the examples seem to be just printing, no passing any data between the nodes. That's not really a realistic scenario, since the main point of a flow graph in my experience is to compute stuff, and you typically need back pressure, queues, priorities etc. to solve real-world problems.
- noneback 2y agoGood point. I will add some typically realistic scenario examples.
- noneback 2y agoI added a more realistic example, parallel_merge_sort, which demonstrates how to pass values and how to avoid a data race among tasks. https://github.com/noneback/go-taskflow/blob/main/examples/parallel_merge_sort/parallel_merge_sort.go https://github.com/noneback/go-taskflow/blob/main/examples/p...
- atombender 2y agoVery helpful, thank you. This also makes it apparent (it wasn't clear to me before) that each graph is declared alongside the data. You cannot reuse a graph to run multiple times on different data; you define the graph every time.
- noneback 2y agoYes. Data is attached to tasks via Go Native variable binding. Values are captured by task function once defined (closure). In some cases, You can change the value of the variable(like changing the value of ptr, rather than ptr itself) and rerun the whole graph to support your cases.