Proposal: Interface-based load balancing strategy for MultiPool

[vibe-sudo]

Hi @panjf2000 ,

I noticed the current load-balancing strategy in MultiPool is implemented as an enum with a switch in next(). It works well, but it has a few limitations:

1. Not extensible — users can't plug in a custom strategy. Take a "least waiting" strategy as an example — picking the pool with the fewest queued tasks rather than the fewest running workers better reflects real backlog pressure when pools are saturated. This could of course be added as a new built-in enum value, but the deeper issue is extensibility: developers should be able to control the selection logic themselves without waiting for upstream changes
2. Duplicated logic — next() is copy-pasted across MultiPool, MultiPoolWithFunc, and MultiPoolWithFuncGeneric
3. State coupling — mp.index (the RoundRobin counter) lives on the pool struct rather than the strategy itself

---

Proposed Design

Introduce a LoadBalancer interface:

type LoadBalancer interface {
    Pick(pools []*Pool) int
    Fallback(pools []*Pool) int // -1 means no fallback supported
}

Built-in strategies (RoundRobin, LeastTasks) become structs implementing this interface. The RoundRobin counter moves into the strategy struct itself.

No breaking change to existing API — NewMultiPool signature stays the same. A new constructor is added for custom strategies:

// existing — unchanged
func NewMultiPool(size, sizePerPool int, lbs LoadBalancingStrategy, options ...Option) (*MultiPool, error)

// new — accepts any LoadBalancer implementation
func NewMultiPoolWithLB(size, sizePerPool int, lb LoadBalancer, options ...Option) (*MultiPool, error)

Internally, NewMultiPool converts the enum to the corresponding built-in LoadBalancer implementation, so MultiPool only holds a single lb LoadBalancer field. The lbs enum field and mp.index field are removed from the struct entirely. The existing fallback behavior (RoundRobin → LeastTasks on overload) is preserved via Fallback().

The result is that Submit becomes simply:

func (mp *MultiPool) Submit(task func()) error {
    idx := mp.lb.Pick(mp.pools)
    if err := mp.pools[idx].Submit(task); err == ErrPoolOverload {
        if fb := mp.lb.Fallback(mp.pools); fb >= 0 {
            return mp.pools[fb].Submit(task)
        }
    }
    ...
}

---

This keeps full backward compatibility while opening up the strategy to user customization. Would you be open to this direction? Happy to adjust the design based on your feedback before opening a PR.

If this proposal is accepted, the same changes will be applied consistently across all three MultiPool variants — MultiPool, MultiPoolWithFunc, and MultiPoolWithFuncGeneric — not just the simplest one.