jigneshsatam/parallel

parallel executes any tasks in parallel by using Golang fanout fanin concurrency pattern

parallel

Concurrency Made Easy

---

 

parallel executes independent tasks in parallel by using Golang fanout fanin concurrency pattern

Installation

go get -u github.com/JigneshSatam/parallel

Usage

Example code snippet: https://play.golang.org/p/uHBw49pwFwt

Step 1: Import the package

import (
	"github.com/JigneshSatam/parallel"
)

Step 2: Create Execute() interface{} method for user defined type

• Let employee be a user-defined type
• Suppose fetching employee details is an independent task and needs to be  done be in parallel
• Create a method Execute() for employee type
• Signature of Execute method Execute() interface{}
• Add the code to fetch the employee details in this Execute() method

// employee -> Let `employee` be a user-defined type
type employee struct {
	name string
}

// Execute() -> Create `Execute() interface{}` method for employee type
func (e employee) Execute() interface{} {
	return employeeDetails(e)
}

func employeeDetails(e employee) string {
	return "Employee details Name: " + e.name
}

Step 3: Call parallel.Run() method

• Call parallel.Run by passing list of employees who's details to be fetched.

func Example() {
	employees := []employee{employee{"foo"}, employee{"bar"}, employee{"baz"}}

	// Call `parallel.Run()` to start parallel execution
	outputChannel := parallel.Run(employees)

	for op := range outputChannel {
		// Cast `interface{}` to desired output type
		output := op.(string)
		fmt.Println(output)
	}
}

// Unordered output:
// "Employee details Name: bar"
// "Employee details Name: foo"
// "Employee details Name: baz"

Contributing

Pull requests are welcome. For major changes, please open an issue first to discuss what you would like to change.

Please make sure to update the tests as appropriate.

License

This project is licensed under the MIT License - see the LICENSE.md file for details

parallel's Issues

【Discuss and Proposal】Some variable name may be better understand if minor changes

1

first， I think the fanout func is send executor to out for async run, the executor run logic real in outer ,
so I think the func addIn name may not be suitable, so may be addOut more better understand.
unless u use executor.addIn something like this to call this func, but i think this func return <-chan interface{},
if use executor.addIn may should not to return something. so this func i think use add or addExecutor or addOut, may be addOut better, because the func's param is executor, when call is very easy readble.

2

second, this func out actually it is receive result from out ， so addToOut actuall it is receive value from out chan ,
so I think inner fanin func addToOut may be receiveFrom better to understand.

Proposal

• I want to add some benchmark for project.
• by the way if u dont mind i change this func name for project.