Re: [go-nuts] Go routines consuming memory

You should read the comments following the article you referenced. In addition there is a long thread on hackernews that might be worth browsing: https://news.ycombinator.com/item?id=36024209 But if you want a real insight into how concurrent programs behave, you are better off writing your own

Re: [go-nuts] Go routines consuming memory

Ha ha. Yes, I am similarly bearded grey. I didn't think it was worth filling in after Etc. I almost stopped reading after ChatGPT on the basis that if you cannot write the simple driver code, you can neither verify that the driver is correct, nor have the understanding of the system needed to

Re: [go-nuts] Go routines consuming memory

Thank you. I had the same reaction. I'm a grey beard who in the past specialized in benchmarking and performance tuning. Synthetic, micro, benchmarks of the type used in that blog post are borderline useless. Especially when comparing different languages. Even when used to measure a single metric

Re: [go-nuts] Go routines consuming memory

This benchmark is worthless for all languages used. - Each Go routine will be given a 2K stack. - Go routines are managed by Go, threads by the operating system. - C# uses a thread pool. - There's a lot wrong with this article, not just with things being claimed about Go. -

[go-nuts] Go routines consuming memory

I was going through a blog where they compare different language threads to see how much memory they consume for a million tasks. Blog : https://pkolaczk.github.io/memory-consumption-of-async/ Do we have any benchmarking/report before that Go routines take more memory with more threads? I

Re: [go-nuts] Can we further optimize the scheduling order of goroutines in sync.Mutex?

I didn't realize that it was already implicitly sorted by time. Thanks for answering 在2023年6月6日星期二 UTC+8 00:27:51 写道： > On Mon, Jun 5, 2023 at 5:08 AM fliter wrote: > > > > Thanks for your answer. But I wonder if the elements behind the queue > may wait for a very long time? Can we maintain a

[go-nuts] Hard-to-explain race detector report

Can someone explain why the following test shows a race between the indicated lines? https://github.com/cespare/misc/blob/b2e201dfbe36504c88e521e02bc5d8fbb04a4532/httprace/httprace_test.go#L12-L43 The race seems to be triggered by the very last line of the test: get(client1) If I comment that

[go-nuts] Re: [golang-dev] [security] Go 1.20.5 and Go 1.19.10 are released

On Tue, Jun 6, 2023 at 11:12 AM wrote: > > cmd/go: improper sanitization of LDFLAGS > > The go command may execute arbitrary code at build time when using cgo. This > may > occur when running "go get" on a malicious module, or when running any other > command which builds untrusted code. This is

[go-nuts] low level sctp driver

Hi, I opened an issue on this GitHub project: https://github.com/ishidawataru/sctp/issues/60 The owner linked to this project: https://github.com/mdlayher/netlink/issues/119 I am not really familiar with low-level network drivers, and honestly, I don't want to dive into it. I'm looking

[go-nuts] [security] Go 1.20.5 and Go 1.19.10 are released

Hello gophers, We have just released Go versions 1.20.5 and 1.19.10, minor point releases. These minor releases include 3 security fixes following the security policy : - cmd/go: cgo code injection The go command may generate unexpected code at build

[go-nuts] Multiple modules, single git repo. That makes sense?

Hi Guys, is it reasonable to publish multiple modules inside single github repo, eg. https://github.com/user/tools/a https://github.com/user/tools/b https://github.com/user/tools/c That seems to be working, but could it create any issues in the future (eg. with version control if I import 2