In one hand, we have a tcpconnect function that supports a waitgroup to report how many connections have been processed, so they can be called inside goroutines and allow the caller to know when everything finished. Now we just decrease the waitgroup when a connection becomes closed. On the other hand, we have an external closure routine that monitors the status of connections and, with the current logic, once everything has progressed to established or errored, closes the program. I never liked this external monitor; this means delay and continuous polling...
The point is then... should we consolidate this in a single approach? Probably making the wg logic smarter, and consider a configurable "termination" policy, would be great.
This issue can be integrated with the new execution modes just as a consideration when implementing configurable termination policies.
In one hand, we have a tcpconnect function that supports a waitgroup to report how many connections have been processed, so they can be called inside goroutines and allow the caller to know when everything finished. Now we just decrease the waitgroup when a connection becomes closed. On the other hand, we have an external closure routine that monitors the status of connections and, with the current logic, once everything has progressed to established or errored, closes the program. I never liked this external monitor; this means delay and continuous polling...
The point is then... should we consolidate this in a single approach? Probably making the wg logic smarter, and consider a configurable "termination" policy, would be great.
This issue can be integrated with the new execution modes just as a consideration when implementing configurable termination policies.