Odd that map would act that way, as map returns a channel which (i would think) could be composed as such. If i execute my example without the doseq put! operation on c1 c2 c3, it does in fact time out at the repl.
the same timeout behavior if i put! on c1 c2, but not c3
a put! on all 3 channels results in "all channels started!"
The thing to understand is map is starting a go block which is basically copying from the input to the output. And your timeout has no effect on that process
It sits there trying to copy until the cows come home
In particular for map, leaving the map process sitting around doing that copying likely is not a big deal
If I recall the output channel is unbuffered and the map process will just wedge writing to it until it gets gc'ed
But in general leaving that kind of process sitting around can cause things to behave unexpectedly (if the channel is buffered, or channels aren't being used as one shot value conveyors)
At the very least I think you'd be better off using something like merge over map, because mapping is ordered and you don't car about order