[go-nuts] Re: Can http.Request.Body be read after http.Client.Do returns?

In pseudo-code, something like this happens: > req := http.NewRequest("POST", url, body) > ... > body.reset() On Monday, 22 July 2019 17:38:14 UTC+3, Gabriel Aszalos wrote: > > I have an odd race condition occasionally occurring in my code (hard to > reproduce i

[go-nuts] Can http.Request.Body be read after http.Client.Do returns?

I have an odd race condition occasionally occurring in my code (hard to reproduce in non-production environment) but it might be hinting at the fact that `http.Client.Do ` might be reading the `http.Request.Body` *after* it returns. Is this possible? I am re-using the

[go-nuts] Can http.Request.Body be read after http.Client.Do returns?

I have an odd race condition occasionally occurring in my code (hard to reproduce in non-production environment) but it might be hinting at the fact that `http.Client.Do` might be reading the `http.Request.Body` *after* it returns. Is this possible? I am re-using the same request body

[go-nuts] Go 1.10 Beta 1 is released

> The grammar for method expressions has been updated to relax the syntax to > allow any type expression as a receiver; this matches what the compilers were > already implementing. For example, struct{io.Reader}.Read is a valid, if > unusual, method expression that the compilers already

[go-nuts] Re: Go predicts the end of the universe

Seems time is on our side. On Friday, 10 November 2017 09:38:37 UTC+1, Hal wrote: > > Go predicts the end of the time, i.e. the end of the universe  > > https://play.golang.org/p/THHvbdo_IS > > package main > > > import ( > "fmt" > "math" > "time" > ) > > > func main() { > endOfTheTime :=

[go-nuts] Re: Go memory usage

Hey Ben, You can use the pprof and trace tools to find answers to those questions yourself. Some links: https://blog.golang.org/profiling-go-programs https://golang.org/pkg/runtime/trace/ https://github.com/pkg/profile justforfunc #22 also talks about using those tools

Re: [go-nuts] Re: Why are two slices in this example less costly than one?

s a post I recently wrote, in case you haven't used pprof with go > code before > > https://blog.fmpwizard.com/2017/09/29/memory-profiling-in-go/ > > Regards, > > Diego > > > >> On Tuesday, 10 October 2017 15:38:58 UTC+2, Ian Lance Taylor wrote: >>> >>> On

Re: [go-nuts] Re: Why are two slices in this example less costly than one?

why they are different. This is exactly what I was trying to figure out how I would be able to do, and more specifically, if there's an easy way to find out. On Tuesday, 10 October 2017 15:38:58 UTC+2, Ian Lance Taylor wrote: > > On Tue, Oct 10, 2017 at 12:50 AM, Gabriel Aszalos > <gabriel...@gm

[go-nuts] Re: Why are two slices in this example less costly than one?

think I'm seeing is that the spans > array is allocated on the stack. Not sure though if this is the only reason. > > Am Donnerstag, 5. Oktober 2017 13:13:56 UTC+2 schrieb Gabriel Aszalos: >> >> I was playing around with the implementation of FieldsFunc from the bytes >>

[go-nuts] Why are two slices in this example less costly than one?

I was playing around with the implementation of FieldsFunc from the bytes package and I was wondering how it would affect the benchmarks to disregard the extra slice that was used there to calculate offsets. It only made sense that it would make things faster. To my amusement (although