On Wed, Aug 21, 2019 at 10:46 PM Michael Jones wrote:
>
> I mentioned it because of the RC status. Was expecting this to resolve before
> release.
>
> Agree that it is no impediment to building. I was imprecise.
Could you see if https://golang.org/cl/191277 fixes the problem on your machine?
Th
I don't think you've posted code for the atomic version...Each Go routine has its own stack. So when you cycle through many Go routines you will be destroying the cache as each touches N memory addresses (that are obviously not shared).That's my guess anyway - the performance profile certainly look
"less than N Go routines it fits in the L1 CPU cache," I am guessing that
you are thinking of local queues on each M, the scheduler's local queue
size is strict to 256 goroutines. However, in our case, all blocking
goroutines don't go the run queue but blocked and stored on semtable, which
is a
Hello gophers,
We have just released go1.13rc1, a release candidate version of Go 1.13.
It is cut from release-branch.go1.13 at the revision tagged go1.13rc1.
Please try your production load tests and unit tests with the new version.
Your help testing these pre-release versions is invaluable.
Re
On Tue, Aug 20, 2019 at 9:53 PM Xiangdong JI wrote:
>
> Thanks Ian.
> Curious to know the purpose of those dummy functions, and for the 'import'
> functions do they have real function bodies?
The dummy functions are there mainly so that the "init" line can list
all imported packages without havi
On Tue, Aug 20, 2019 at 6:42 PM Gert wrote:
>
> https://golang.org/doc/asm
>
> $ cat x.go
> package main
>
> func main() {
> println(3)
> }
> $ GOOS=linux GOARCH=amd64 go tool compile -S x.go# or: go build
> -gcflags -S x.go
>
> --- prog list "main" ---
> (x.go:3) TEXTmain+0(SB),
On Wed, Aug 21, 2019 at 10:18 AM Robert Engels wrote:
>
> I understand the first part, but the second? Why is the finalizer function
> passed a reference to the object being finalized then?
There are cases where the finalizer function does want to refer to the
object, such as the finalizer on os
I understand the first part, but the second? Why is the finalizer function
passed a reference to the object being finalized then?
-Original Message-
>From: Ian Lance Taylor
>Sent: Aug 21, 2019 12:06 PM
>To: Robert Engels
>Cc: zct , golang-nuts
>
>Subject: Re: [go-nuts] A problem ab
On Wed, Aug 21, 2019 at 9:14 AM Robert Engels wrote:
>
> Seems like GoLint should emit an 'unused parameter' in this case.
It's normal for a function to have an unused parameter. And in
particular it's normal for a finalizer to not refer to the object
being finalized.
Ian
> -Original Mess
On Tuesday, August 20, 2019 at 7:58:29 PM UTC-4, joe mcguckin wrote:
>
> Using Dave Cheney's profile package to figure out the execution path of a
> library I'm trying to understand.
>
> The application starts, (it's a server), I hit ^c after a couple of
> minutes, and the console says
>
>
Seems like GoLint should emit an 'unused parameter' in this case.-Original Message-
From: zct
Sent: Aug 21, 2019 10:50 AM
To: golang-nuts
Subject: Re: [go-nuts] A problem about runtime.SetFinalizer
I got it.Thank you for your help在 2019年8月21日星期三 UTC+8下午11:00:26，Ian Lance Taylor写道：On Wed,
I got it.Thank you for your help
在 2019年8月21日星期三 UTC+8下午11:00:26，Ian Lance Taylor写道：
>
> On Wed, Aug 21, 2019 at 5:55 AM zct > wrote:
> >
> > I recently had a goroutine leak problem, the code i reduced is like
> this: https://play.golang.org/p/YW4hWoZZ7CD.
> >
> > The program is long-runnin
On Wed, Aug 21, 2019 at 5:55 AM zct wrote:
>
> I recently had a goroutine leak problem, the code i reduced is like this:
> https://play.golang.org/p/YW4hWoZZ7CD.
>
> The program is long-running and the finalizer is not called
>
> The RoomObj is deleted from map， why was it not released？ Is it re
I am using a library which is watching a NAS directory for changes using
golang syscall on windows platform.
while making syscall.GetQueuedCompletionStatus I am getting value of qty as
0, I tried to check the syscall source code but not able to debug it.
syscall source code is one of the comp
I recently had a goroutine leak problem, the code i reduced is like this:
https://play.golang.org/p/YW4hWoZZ7CD.
The program is long-running and the finalizer is not called
The RoomObj is deleted from map， why was it not released？ Is it refereed by
the asyncChan object？
I don't understand he
For just the exponential backoff part, you might want to take a look at
https://godoc.org/gopkg.in/retry.v1 which provides easily pluggable retry
strategies, including exponential backoff with jitter, and you can write
your code as a normal for loop - no awkward callback to use.
cheers,
rog.
16 matches
Mail list logo
