Re: [go-nuts] Re: go routines not being deallocated

This might be https://github.com/golang/go/issues/34457 (at least, Brian's repro). When a goroutine finishes, we deallocate its stack, and that deallocation will eventually be given back to the OS. The Goroutine descriptor, however, will live forever. We'll reuse it for new goroutines, but it ne

[go-nuts] Purpose of TimeoutHandler

Hi all - I wrongly assumed that the TimeoutHandler() is supposed to help application authors free up resources on the sever for anything running than the expected duration of time. However that doesn’t seem to be the case. The inner handler continues running, only the client gets a 503 after the

Re: [go-nuts] Is unsafe.Pointer(reflect.Value.UnsafeAddr()) safe?

Again, the rules are very clear and in accordance with what's been said here (both by OP and by you): (5) Conversion of the result of reflect.Value.Pointer or > reflect.Value.UnsafeAddr from uintptr to Pointer. Package reflect's Value methods named Point

Re: [go-nuts] Re: go routines not being deallocated

This is memory allocated as reported by go itself, not by the OS. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To vie

Re: [go-nuts] Re: go routines not being deallocated

Just to note, from a Perl background (learning Go atm so this may not apply, just trying to indicate it may be "normal"), I think this isn't necessarily unusual for a process to not free up memory, and it's an OS limitation (again I may be barking up the wrong tree). Elsewhere (i.e not Go), I've go

Re: [go-nuts] Is unsafe.Pointer(reflect.Value.UnsafeAddr()) safe?

What's your platform? On M1, checkptr reports an error for me. The code: ptr := unsafe.Pointer(rf.UnsafeAddr()) is safe, but: x := rf.UnsafeAddr() ptr = unsafe.Pointer(x) is not. Cuong Manh Le https://cuonglm.xyz On Sun, Apr 18, 2021 at 6:46 AM Name No wrote: > > reflect.Value.UnsafeAdd

[go-nuts] Re: 9% performance loss with 1.16.3 vs. 1.15.11

I read up on that and agree that it seemed like a probable cause. However tests show no difference. [image: go_perf2.png] On Sunday, April 18, 2021 at 10:25:09 AM UTC+2 Brian Candler wrote: > Could you compare with go 1.15 running with GODEBUG=madvdontneed=1 ? > That's now standard behaviour

[go-nuts] Re: go routines not being deallocated

>From further research (and anybody correct me if this is wrong), when the GC does collect memory the profile shrinks, but *no memory is returned to the system*. Any future allocations will try to use memory from the pool of previously collected objects before asking the system for more. This i

[go-nuts] Re: go routines not being deallocated

Also, I don't think it's the Stack. If you replace Alloc with HeapAlloc... it's all there. On Sunday, April 18, 2021 at 12:33:20 PM UTC-5 Trig wrote: > Correct... the example using time.Sleep didn't run on the playground. The > original post I made, I provided the link with just a goroutine w

[go-nuts] Re: go routines not being deallocated

Correct... the example using time.Sleep didn't run on the playground. The original post I made, I provided the link with just a goroutine with an empty function. At least you were able to reproduce what I'm inquiring about. I'll look further into this, but surely unused and finished goroutine

Re: [go-nuts] Is unsafe.Pointer(reflect.Value.UnsafeAddr()) safe?

Not "raise an exception", "make an exception". Go doesn't have exceptions, so the word "exception" here means "not do something you'd otherwise do" - namely "complain about the conversion of a uintptr to an unsafe.Pointer" :) The exact rules for converting to and from unsafe.Pointer are here: http

[go-nuts] Re: go routines not being deallocated

What do you mean by "It won't work on the playground"? It runs for me. Are you saying you get different results when running locally? If so, what version of go are you running locally, on what platform, and what do you see? Or are you saying the problem is really with something like this? ht

[go-nuts] Re: 9% performance loss with 1.16.3 vs. 1.15.11

Could you compare with go 1.15 running with GODEBUG=madvdontneed=1 ? That's now standard behaviour in 1.16. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to gola