Advanced Golang: Limiting Goroutines

[@akhil_sai]

Thank you 3:40 It could be struct{} if it is just for signaling process, no memory allocation needed.

[@daviidon]

The technical term is a counting semaphore. It would be interesting to see the performance of using a pool instead of spawning new go routines.

[@k98killer]

I just started playing with Go last week. This morning, I wrote a chat server that uses a defacto pool of goroutines where each goroutine resets after the connection drops. I'm pretty stoked about it.

[@riteshgsh]

​@@k98killer hey could u share the code?

[@k98killer]

@@riteshgsh I found a bit later (after switching back to Python as my main language) that there were some bugs in it. I haven't yet figured out how the bugs are caused to fix them, so it's probably not the best example to reference.

[@waldiniman]

@@k98killersuch is the nature of coding

[@abiiranathan]

Counting Semaphore pattern

[@LesterFernandezIO]

I love the diversity of content on this channel. I used to do game dev with Unity and I’ve been doing TypeScript for a while and now I’m getting into Go, so I relate a lot with your content 😂

[@codewithryan]

Haha glad to hear!

[@MattBolt35]

Would it be fair to say that the reason this application is being killed at the 200MiB limit is more about what the Process() func is allocating, and not really about the goroutines? I agree that for this specific use case, limiting the # of concurrently running goroutines will implicitly limit the number of concurrent Process() allocations being made? Goroutines are exceptionally lightweight at a 2kb stack. Busy backends can use thousands of goroutines no problem. You conveyed limiting the number of go routines running for the Process() function wonderfully. Go's memory allocation can make it frustrating to deal with, and I've found the bounded channel approach you explained here to be an amazing way to control concurrent memory-hungry functions. Great content sir!

[@thingfish5271]

Ryan, great channel! One of the better channels for experienced devs wanting to grasp Go concepts quickly but communicated well enough for beginners to use.

[@BryceChudomelka]

Single best explanation of why buffered channels. Thanks.

[@hardikvegad3508]

You explain concepts very clearly can you please create a complete course on go... It would be helpful Thanks!

[@MrTyty527]

Have been doing Golang for a few months. These contents are great!

[@BelgianNoise]

With all the respect, you look like someone who knows what he's talking about :) . And I am now using this in my application.

[@Dsouza10082]

Amazing, one of the best so far, thank you !

[@erix100100]

Great video with clear explanation!

[@Gabriel-eq1yu]

GREAT go content! Thanks a lot for sharing.

[@Draxen]

Subscribing bro!! Just started learning GO myself after being a typescript dev for the last few years. Awesome content man!! Keep it up 🤘

[@nono-dw8yk]

Hey, just to let you know that your content is pretty good, keep it up!

[@user-dz6il2bx5p70]

Awesome content and explanation, thank you.

[@guhkunpatata3150]

Great explanation. thank you Ryan!

[@baz_sh]

This was a great video. It would be cool to be able to get at the code and play around with it.

[@mohammadseddighi5501]

are we gonna see any new video from this channel ? i found this channel today and its awesome

[@tp1558]

I'm more interested in those monitoring bro. That's rad.

[@sczoot6285]

Not sure if you are avoiding this because you don't want to get into it in the scope of this video but if you are passing a completely arbitrary value as a signal to a chan you almost always want to use type of struct{}. There's several good articles on why this is by Dave Cheney and others but essentially it uses no storage and is perfect for the use case in the video

[@arjundhar7729]

There is no memory limiter @ the routine level I think. That would be cool to sandbox at the routine level instead of process level.

[@themarksmith]

Excellent video, thank you - I'm learning Golang and I am interested in using Golang with WebSockets rather than RabbitMQ (which I've had a play with) - so any vids on that topic would be of interest...

[@syamprasad6038]

how you connected container with Go program, how the container showing memory usage when you run the Go program? can you make a detailed video on this one please

[@ej.xxxx_]

docker stats

[@amerispunk]

Ryan this is the only video from you that I've seen but I just wanted to tell you that your audio sounds like it's over-driven and distorted. I think if you would cut back on your mic gain by around 30% you would sound a lot better. Otherwise your content is great.

[@ohLyln]

Hey Ryan! This video was awesome I have never seen something like this and you presented it in a way I just intuitively grasped. On question: what is that streaming / events package? Is it in the stdlib? I have an app right now at work that needs to stream data and throttle it and it’s kind of an ugly mess and I think I could clean it up a ton with that package and what you showed here.

[@iskanderabbassi6256]

I love it

[@mohsanabbas6835]

I encountered this disgusting 🤢 behavior in one of my app it occurred while topic lag processing, Go routine’s really can become ghost if you give them free hand

[@abishekkumar316]

which tool is being used to visualize the memory, and CPU for docker?

[@ej.xxxx_]

docker stats

[@arjundhar7729]

What's the video editing software you are using? I like the zoom and roam you do

[@AntonAverin]

So Go doesn't have a concept of pool? That is a bit unfortunate as if you have many places in the codebase that use goroutines, managing this kind of limiting will be problematic.

[@squ34ky]

It does. The `sync` package also provides some helpers to ease working with concurrency patterns including pools.

[@rohitchoudhary1800]

nice

[@kitastro]

one of the previews of this video has a typo

[@mutazal-ashhab8068]

Can you make the code public? If yes, could you add the dockerfile as well

[@andohache]

What about if ProcessEvent panic? Shouldn't we defer

[@therelatableladka]

Yess actually this is how it should be. Ryan actually just did that one to show what actually happens

[@williamzapata6710]

Hi What course do you recommend to learn Golang to make APIs and microservices?

[@TheDavBag]

do we have a method to calculate our goroutines capacity? I mean not just pick on the go

[@sanketneema286]

Ryan how you are print the number of routines running concurrently.

[@segeus]

What about usage of an empty structure (struct{}) for a signal channel? As far as I know an empty structs in go take nearly 0 byte.)

[@jannachname168]

this is true. he said "it could be anything you want" so empty struct is covert.

[@hectordepablos9791]

cannot find package multithreading2/pkg/events, how do I install it, I can't recreate the example, what is the version of go? please!!

[@isuryanarayanan506]

yeah same, i cant find it anywhere

[@alexanderp4532]

7:00 well, the way you did it is not efficient at all. You want to limit the number of goroutines by 10, so you know that at the same time you won't have more than 10 workers, why don't you use worker pool pattern instead of semaphore, which in the video? More efficient way is to not spawn and kill goroutine, which has a little overhead, because we need to allocate and clean stack for each goroutine, but to keep them running as much as possible

[@vcool]

Exactly. The author doesn't seem to know what he's doing. The overhead of goroutines makes it a bad idea to use them in such a disposable way when there are billions or trillions of events that need to be processed. He shows his bad pattern in multiple videos too. A worker pool would be more CPU efficient. Even with a worker pool, I check for system load to limit the number of active workers so as to prevent CPU contention.

[@mydogiscoolasheck]

​@@vcool The cost of spawning a goroutine is pretty small, and not everyone is dealing with billions or trillions of events. Author did a great job showcasing a simple strategy to avoid OOM panics.

[@Tarekconqueso]

is my comment really an event ? checking out the dev tools dont mind me