[go-nuts] Memory usage do not reconcile between pprof vs top

hi all, I've been doing some memory profiling on my application, but I see there's a big disparity between the memory usage reported by pprof and what the system think it is using. My application binary (compiled with go1.9.2) is about 22MB running on FreeBSD v11 on AWS (but I see the

Re: [go-nuts] Re: Long running task in select case

to be clear, nobody's "reputation" is impugned here--i mean, not really. this is about logic and engineering and sharing knowledge. asking about edge conditions and what happens when rules are violated is all fair game. sorry if i sounded too strong. the crux of the "safe race" idea is most

Re: [go-nuts] Re: Long running task in select case

> > Only if it doesn't leave the shop like that, but with a P>0, it will. Before commit I usually go through many iterations, but what I shared was iteration one. I’m confident that iteration two wouldn’t have the data race in my case. I don’t think these playgrounds are a good place to

Re: [go-nuts] Re: Long running task in select case

Only if it doesn't leave the shop like that, but with a P>0, it will. On Sat, 2018-03-17 at 15:24 -0700, matthewju...@gmail.com wrote: > Defending my reputation, I’m here for people making things, not for > being  > an educator. Thinking quickly and making it work even with mistakes > can be  > a

Re: [go-nuts] Re: Long running task in select case

Defending my reputation, I’m here for people making things, not for being an educator. Thinking quickly and making it work even with mistakes can be a valid approach sometimes. Matt On Saturday, March 17, 2018 at 2:05:55 PM UTC-5, Michael Jones wrote: > > these are excellent answers. > > i

Re: [go-nuts] Re: Long running task in select case

these are excellent answers. i offer a harsher one:* the wrong answer faster is not optimization. *the law of programming has correctness at its core--imagine reasoning about a program where "if 5 < 7{stuff}" executed 50% of the time, or even 99.% of the time. if it was faster, that simply

[go-nuts] Re: Long running task in select case

Hi all, In this particular case, this is a toy example of course, but for this toy example, it is absolutely a case where the performance of the synchronization primitive literally does not matter at all. (If I followed here, the intent is seemingly to watch a long running task, and the

[go-nuts] Re: Long running task in select case

On Saturday, March 17, 2018 at 10:37:48 AM UTC-4, matthe...@gmail.com wrote: > > I think the second example alternative given (playground link above) has a >> data race? > > > I’m not surprised that the race detector sees something (a read can happen > during a write of the checked bool) but I

[go-nuts] Re: Long running task in select case

> > I think the second example alternative given (playground link above) has a > data race? I’m not surprised that the race detector sees something (a read can happen during a write of the checked bool) but I don’t think this could actually cause problems because the var’s memory value will

[go-nuts] Re: Long running task in select case

> > *> "Here's another way: https://play.golang.org/p/gEDef3LolAZ > "* Hi all, I think the second example alternative given (playground link above) has a data race? Sample race detector run just now. (The two reports are inverses of each other: read

[go-nuts] Re: Long running task in select case

Leaving aside the channel being non-nil, none of the others are a clear way to solve this. They all involve either repeatedly checking on a timer or checking the value of another field (like polling) to see whether the long running task should be stopped. Is there no other way to do this

Re: [go-nuts] an "append" use, bug or intended design?

On Saturday, March 17, 2018 at 1:54:17 AM UTC-4, T L wrote: > > > > On Friday, March 16, 2018 at 3:31:23 PM UTC-4, Axel Wagner wrote: >> >> >> >> On Fri, Mar 16, 2018 at 8:20 PM, T L wrote: >> >>> >>> >>> On Friday, March 16, 2018 at 2:57:48 PM UTC-4, Jan Mercl wrote: