Sometime I really don't understand why the fact there are many Go Developer, but some advanced in Go tutorials, introductions, ... was lack of viewers...
Very late to the party here, but nevertheless; if you go to 18:57 you can see that the startFetch channel is derived from the variable next, which is governed by what is returned from s.fetcher.Fetch() where the fetcher is of type Fetcher which comes from an external rss package. So to distill it down, the startFetch is a directly a function of Fetcher.Fetch() which we trust for giving us the correct interval of fetching the RSS feeds (see 6:45 for the Fetcher.Fetch() signature). Therefore to answer your question, if the fetch is very frequent then yes in some cases it might delay returning updates (I say might because select chooses a case to run at random if more than one case is non-blocking, so the update function will be called more times than we expect it to under very frequent fetch requests), but the code in the video above won't behave that way (as we are trusting the rss packages Fetch behavior).
why the pipeline model is meged the multiple channels to one ,not multiple subscription items write to one global channel at once. I think this can simply this pipeline model
sucks when you see "naive impl" slides and think "damn, that's exactly how i would've impl'd it".
i vibe with this
It's normal, that's how you learn
Need more of talks like this :)
Sometime I really don't understand why the fact there are many Go Developer, but some advanced in Go tutorials, introductions, ... was lack of viewers...
It would have been nice if you could keep the code up there a while. I do not need to see the speaker so much, I need to see the code.
you could just pause uk
The improved Close() can only be called once, any further calls will block forever. What's the preferred solution to this, sync.Once?
Keep the focus on the slides. So annoying...
"Responsive. Cleans up. Easy to read and change." The code is easy to read???
yes
Can anyone send a link to full example code, please?
It's year later, but here they are
talks.golang.org/2013/advconc.slide#38
github repo: github.com/golang/talks/tree/master/content/2013/advconc
So how many mainthread 5 or 10 that you switch between
Should show the complete code as I don't quite follow.
damn I am 1 decade late
It's amazing that this talk is still very informative.
21:45 if there is a new fetch all the time wouldn't that delay returning updates, since both cases are active at the same time?
Very late to the party here, but nevertheless; if you go to 18:57 you can see that the startFetch channel is derived from the variable next, which is governed by what is returned from s.fetcher.Fetch() where the fetcher is of type Fetcher which comes from an external rss package. So to distill it down, the startFetch is a directly a function of Fetcher.Fetch() which we trust for giving us the correct interval of fetching the RSS feeds (see 6:45 for the Fetcher.Fetch() signature).
Therefore to answer your question, if the fetch is very frequent then yes in some cases it might delay returning updates (I say might because select chooses a case to run at random if more than one case is non-blocking, so the update function will be called more times than we expect it to under very frequent fetch requests), but the code in the video above won't behave that way (as we are trusting the rss packages Fetch behavior).
The s.close() and s.closed is shown nowhere in the slides. and where is the code repo? I only see the slides link.
why the pipeline model is meged the multiple channels to one ,not multiple subscription items write to one global channel at once. I think this can simply this pipeline
model
great talk
you know what would be nice? 7 year later... to have a 2x, 3x accelerator in youtube client...
mind blowing
super
nice! thanks
👌🏾👌🏾
What the hell happened!!