I think adding a project to your issue that demonstrates the problem would make things easier to understand. On May 10, 2025, at 11:45 PM, Jason E. Aten wrote:Is there a way to insure I've only got one versionof a package in a build? I need to make surea single mutex is used by all goroutines.De
I don’t think a Go program can have two different version of the same package. That is what go.mod ensures and why most (all?) Go builds require access to all source code. On May 10, 2025, at 11:45 PM, Jason E. Aten wrote:Is there a way to insure I've only got one versionof a package in a build?
Is there a way to insure I've only got one version
of a package in a build? I need to make sure
a single mutex is used by all goroutines.
Detailed back story is here:
https://github.com/golang/go/issues/73665
--
You received this message because you are subscribed to the Google Groups
"golang-
The two most likely limiters in performance will be your network pipe to
the cloud and the QPS quota offered by the service. If you are not reaching
those limits you should increase the parallelism until you do. If your cpu
becomes saturated first you probably need larger buffer sizes in the I/o
If you are asking how to benchmark variations of a design, rather an
improve an existing one, this is a nice survey of tools:
https://betterstack.com/community/guides/scaling-go/golang-benchmarking/
The classic pprof intro which gives a step by step example is:
https://go.dev/blog/pprof
On Friday
On Tue, Apr 1, 2025 at 10:24 AM GoStriver wrote:
>
>
> I noticed that the source code mentions in many places that timers depend on
> netpoll. However, I understand that timers are triggered via
> pp.timers.check() within findRunnable(). How exactly do timers rely on
> netpoll then? Am I missin