The most detailed explanation that exists on the subject on youtube. At timestamp 17:20, To block the func fanIn from returning, You have moved the `wg.Wait()` in a separate Go Routine. Could you please explain, Why is that?
@@a_maxed_out_handle_of_30_chars I guess the "fanIn" function must return immediately with the newly created channel such that the "main" block starts reading concurrent writes on it. However, main function would still be held up until all go routines complete which is what we want.
so using the Fanout and fanin pattern the order of data is not maintained? Is there any way to print the data with same order like how it was in the csv file?
@@harry-cee so using the Fanout and fanin pattern the order of data is not maintained? Is there any way to print the data with same order like how it was in the csv file?
@@hrishekessaraghu5778 As such with any concurrent and parallel processing, You ideally want each job to finish and clear as quickly it can. There shouldn't be any reason to hold out routines for other jobs to finish. You might want to consider an aggregator/ sorter function to take all the results and sort them as you desire before writing to a csv, for instance.
was gonna ask the same. If someone can benchmark both cases, I want to find out as well. But even if there is no difference, it's a good example for teaching purposes.
wg.Wait has to be in separate routine becuase since we are sending to out channel and no one will be reading out from channel if wg.Wait is not inside go routine as wg.Wait will block main routine until all go routines are completed wg.wait has to be in separate go routine so that it is read from out channel other wise all routines will get blocked
so using the Fanout and fanin pattern the order of data is not maintained? Is there any way to print the data with same order like how it was in the csv file?
you can give an id to each city and when done with the all the channels, you can create a slice and put them in their initial order. For that you need to know the length of the csv file. One way you can do that is while running the first go routine count the lines at the same time and send that number in a countChannel. In the main then, you can read from that countChannel and create the final results slice with make([]int, 0, count)
thanks, great vid. Are there any fan out patterns where wokers don't have to compete i.e the fan out channel blocks until all workers have consumed the message.
Thanks for this tutorial. This channel is the most underrated Go tutorial on yt. Please keep it up.
❤ thank you bro
The most detailed explanation that exists on the subject on youtube. At timestamp 17:20, To block the func fanIn from returning, You have moved the `wg.Wait()` in a separate Go Routine. Could you please explain, Why is that?
I've same question
@@a_maxed_out_handle_of_30_chars I guess the "fanIn" function must return immediately with the newly created channel such that the "main" block starts reading concurrent writes on it. However, main function would still be held up until all go routines complete which is what we want.
so using the Fanout and fanin pattern the order of data is not maintained? Is there any way to print the data with same order like how it was in the csv file?
@@harry-cee so using the Fanout and fanin pattern the order of data is not maintained? Is there any way to print the data with same order like how it was in the csv file?
@@hrishekessaraghu5778 As such with any concurrent and parallel processing, You ideally want each job to finish and clear as quickly it can. There shouldn't be any reason to hold out routines for other jobs to finish. You might want to consider an aggregator/ sorter function to take all the results and sort them as you desire before writing to a csv, for instance.
It was quite intuitive!
Great video as usual thank you
Thanks for watching!
How is it better than, for example, just transforming regular slice of City structs? Is it faster?
was gonna ask the same. If someone can benchmark both cases, I want to find out as well. But even if there is no difference, it's a good example for teaching purposes.
greate video, helpfull to understanding concurrency
useful information Thanks
Hey this a great tut. At about 18.30 you put wg.Wait in an anonymous goroutine func. Why is that? I 'm thinking that wg,Wait blocks anyway?
wg.Wait has to be in separate routine becuase since we are sending to out channel
and no one will be reading out from channel if wg.Wait is not inside go routine
as wg.Wait will block main routine until all go routines are completed wg.wait
has to be in separate go routine so that it is read from out channel other wise all routines will get blocked
Awesome! 👍
😊 🙏 😊
thank you so much for sharing.
this taught me a few things.
Thanks Victor happy that you learned something new
Amazing!
so using the Fanout and fanin pattern the order of data is not maintained? Is there any way to print the data with same order like how it was in the csv file?
you can give an id to each city and when done with the all the channels, you can create a slice and put them in their initial order. For that you need to know the length of the csv file. One way you can do that is while running the first go routine count the lines at the same time and send that number in a countChannel. In the main then, you can read from that countChannel and create the final results slice with make([]int, 0, count)
thank you for the video
Thanks for watching!
thank you, very clear!
thanks, great vid. Are there any fan out patterns where wokers don't have to compete i.e the fan out channel blocks until all workers have consumed the message.
Depending on the circumstances, contexts might be used for this purpose.
We really like you bro
Thanks for the support bro
great tutorial thank you!