Re: [go-nuts] Go routines stuck in runtime_pollwait

[Siddhesh Divekar]

That's right Kurtis, we don't wait or check if the prior go routine which
fired the big query has completed or not.
The rationale there was the data which comes out from big query is not much
and should not take more than 2 mins.

To be precise every 2 mins we will fire 6 independent Big queries & 24
independent elastic queries each in its own go routine.
The data coming out is cached locally and when the user requests that data
we serve it out of cache.

What we are unable to understand is why would this cause http server to
stop responding to user requests which are not coming for this data.
Regular requests were also not getting served. Since the system was
responding we had to send sig abort and collect the back trace.


goroutine 3332366 [select, *79 minutes*]:
net/http.(*http2ClientConn).*roundTrip*(0xc003759b00, 0xc00050b700, 0x0,
0x0, 0x0, 0x0)
/usr/local/go/src/net/http/h2_bundle.go:7573 +0x9a0
net/http.(*http2Transport).*RoundTripOpt*(0xca0480, 0xc00050b700,
0xc0037a8600, 0x74aba5, 0x0, 0xc0001c8000)
/usr/local/go/src/net/http/h2_bundle.go:6936 +0x172
net/http.(*http2Transport).*RoundTrip*(...)
/usr/local/go/src/net/http/h2_bundle.go:6897
net/http.http2noDialH2RoundTripper.*RoundTrip*(0xca0480, 0xc00050b700,
0xc0047e97a0, 0x5, 0xc0001c8088)
/usr/local/go/src/net/http/h2_bundle.go:9032 +0x3e
net/http.(*Transport).*roundTrip*(0x5b48c00, 0xc00050b700, 0x2b3ce20,
0x5b48801, 0xc0048deb00)
/usr/local/go/src/net/http/transport.go:485 +0xdc8
net/http.(*Transport).*RoundTrip*(0x5b48c00, 0xc00050b700, 0x3301658, 0xa,
0xc0048debd0)
/usr/local/go/src/net/http/roundtrip.go:17 +0x35
google.golang.org/api/transport/http.(*parameterTransport).*RoundTrip*(0xc0028d9e40,
0xc00050b600, 0x5, 0x5, 0x0)
/builds/fusionio/fusion/controller/gopath/pkg/mod/
google.golang.org/api@v0.19.0/transport/http/dial.go:145 +0x224
go.opencensus.io/plugin/ochttp.(*traceTransport).*RoundTrip*(0xc00284d6c0,
0xc00050b600, 0xc002080980, 0x1, 0x1)

/builds/fusionio/fusion/controller/gopath/pkg/mod/go.opencensus.io@v0.22.3/plugin/ochttp/trace.go:84
+0x456
go.opencensus.io/plugin/ochttp.statsTransport.*RoundTrip*(0x38d4e60,
0xc00284d6c0, 0xc00050b400, 0xc0025e27e0, 0xc0025e27e0, 0x2ecb720)

/builds/fusionio/fusion/controller/gopath/pkg/mod/go.opencensus.io@v0.22.3/plugin/ochttp/client_stats.go:57
+0x5cc
go.opencensus.io/plugin/ochttp.(*Transport).*RoundTrip*(0xc003731d60,
0xc00050b400, 0x0, 0x0, 0x150)

/builds/fusionio/fusion/controller/gopath/pkg/mod/go.opencensus.io@v0.22.3/plugin/ochttp/client.go:99
+0x20e
golang.org/x/oauth2.(*Transport).*RoundTrip*(0xc00376bc20, 0xc00050b300,
0x0, 0x0, 0x0)
/builds/fusionio/fusion/controller/gopath/pkg/mod/
golang.org/x/oauth2@v0.0.0-20200107190931-bf48bf16ab8d/transport.go:55 +0xf4
net/http.send(0xc00050b300, 0x38d5060, 0xc00376bc20, 0x0, 0x0, 0x0,
0xc0036a64c8, 0x1d6cede, 0x1, 0x0)
/usr/local/go/src/net/http/client.go:250 +0x443
net/http.(*Client).send(0xc003afdb60, 0xc00050b300, 0x0, 0x0, 0x0,
0xc0036a64c8, 0x0, 0x1, 0x0)
/usr/local/go/src/net/http/client.go:174 +0xfa
net/http.(*Client).do(0xc003afdb60, 0xc00050b300, 0x0, 0x0, 0x0)
/usr/local/go/src/net/http/client.go:641 +0x3ce
net/http.(*Client).Do(...)
/usr/local/go/src/net/http/client.go:509
google.golang.org/api/internal/gensupport.send(0x393ede0, 0xc00346b8c0,
0xc003afdb60, 0xc00050b200, 0x5b7fee0, 0xc0037a9300, 0x1d6f876)
/builds/fusionio/fusion/controller/gopath/pkg/mod/
google.golang.org/api@v0.19.0/internal/gensupport/send.go:67 +0xef
google.golang.org/api/internal/gensupport.SendRequest(0x393ede0,
0xc00346b8c0, 0xc003afdb60, 0xc00050b200, 0xc0037a95e8, 0x84, 0x0)
/builds/fusionio/fusion/controller/gopath/pkg/mod/
google.golang.org/api@v0.19.0/internal/gensupport/send.go:52 +0x193
google.golang.org/api/bigquery/v2.(*JobsGetQueryResultsCall).doRequest(0xc0037a98f8,
0x32f6d9c, 0x4, 0x0, 0x0, 0x203001)
/builds/fusionio/fusion/controller/gopath/pkg/mod/
google.golang.org/api@v0.19.0/bigquery/v2/bigquery-gen.go:7768 +0x765
google.golang.org/api/bigquery/v2.(*JobsGetQueryResultsCall).Do(0xc0037a98f8,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
/builds/fusionio/fusion/controller/gopath/pkg/mod/
google.golang.org/api@v0.19.0/bigquery/v2/bigquery-gen.go:7780 +0xa8
cloud.google.com/go/bigquery.(*Job).waitForQuery.func1(0x6d183a,
0xc0037a97c0, 0xc0037a97e0)
/builds/fusionio/fusion/controller/gopath/pkg/mod/
cloud.google.com/go/bigquery@v1.4.0/job.go:320 +0x48
cloud.google.com/go/internal.retry(0x393ede0, 0xc00346b8c0, 0x3b9aca00,
0xdf8475800, 0x4000, 0x0, 0xc0037a98e0, 0x3433818, 0x0,
0x203000)
/builds/fusionio/fusion/controller/gopath/pkg/mod/
cloud.google.com/go@v0.53.0/internal/retry.go:38 +0x48
cloud.google.com/go/internal.Retry(...)
/builds/fusionio/fusion/controller/gopath/pkg/mod/
cloud.google.com/go@v0.53.0/internal/retry.go:31

Re: [go-nuts] Go routines stuck in runtime_pollwait

[Kurtis Rader]

On Wed, Aug 26, 2020 at 8:51 PM Siddhesh Divekar 
wrote:

> Right, then it looks less likely that we are blocked on a mutex.
>
> Every 2 minutes we spin up a go routine which then in turn spins up a
> bunch of go routines to collect data from big query & elastic (data
> collector routines).
> The 2 minutes go routine then in turn waits on waitgroup for data
> collector routines to come back. So its not single go routine from our side
> at least.
> From backtrace we have from sigabort we see only one such data collector
> go routine blocked and other 2 2 mins thread waiting on waitgroup.
>

Are you spinning up a Go routine every 2 minutes regardless of whether the
previous instance had completed? Your comment is not clear whether you have
one, or more than one, goroutine issuing a BigQuery query at the time you
saw the problem and captured the backtraces. If you are, in fact, starting
those Go routines without regard to whether the prior instance had
completed that seems like a "yellow flag", "here be dragons", situation.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD-y%3DQg_dx5W0qDWiMV9sB0eFToTEoiD83_mbn7RHC%3DQ%3Dg%40mail.gmail.com.

Re: [go-nuts] Go routines stuck in runtime_pollwait

[Siddhesh Divekar]

Typo.

>From backtrace we have from sigabort we see only *2* such data collector go
> routine blocked and other 2 2 mins thread waiting on waitgroup.



On Wed, Aug 26, 2020 at 8:50 PM Siddhesh Divekar 
wrote:

> Right, then it looks less likely that we are blocked on a mutex.
>
> Every 2 minutes we spin up a go routine which then in turn spins up a
> bunch of go routines to collect data from big query & elastic (data
> collector routines).
> The 2 minutes go routine then in turn waits on waitgroup for data
> collector routines to come back. So its not single go routine from our side
> at least.
> From backtrace we have from sigabort we see only one such data collector
> go routine blocked and other 2 2 mins thread waiting on waitgroup.
>
> I see similar issues on the internet. Kubernetes hit the following issue
> which has exactly the same signature as us.
>
> https://github.com/kubernetes/kubernetes/issues/53191
>
> I will follow up with big query guys to see what their behavior is. If one
> of the requests gets stuck on big query, what do they do with
> other requests?
> But in that case in our back trace we should see all other requests
> waiting in their code which is not the case.
>
>
>
> On Wed, Aug 26, 2020 at 7:44 PM Robert Engels 
> wrote:
>
>> If you look at the stack trace the futex is because it is trying to
>> shutdown the entire process - killing all of the M’s - probably because you
>> sent the sigabort
>>
>> On Aug 26, 2020, at 9:41 PM, Robert Engels  wrote:
>>
>> 
>> The big query client may be “single threaded” meaning you may need a pool
>> of connections. Not sure - haven’t used the BQ library from Go.
>>
>> If that’s the case a single slow query will block all of your connections
>> (if they are all accessing BQ). Plus there are BQ rate limits - when you
>> hit those the connector may block - again blocking all clients.
>>
>> On Aug 26, 2020, at 8:27 PM, Siddhesh Divekar 
>> wrote:
>>
>> 
>> Robert,
>>
>> That's where the confusion is.
>> From the backtrace we see that two go routines are blocked on the
>> waitgroup.
>> The go routine on which they are blocked is waiting on big query to
>> return.
>>
>> On every user request we create a new go routine so they shouldn't get
>> blocked because of these two.
>>
>> However, we do see one go routine blocked on futex. Is there a way to
>> know from where it originated from ?
>> When does golang use futex under the hold so that we can investigate from
>> that angle.
>>
>> goroutine 0 [idle]:
>> runtime.futex(0x5b607a8, 0x80, 0x0, 0x0, 0x0, 0x7ffc5dd1bd20, 0x437640,
>> 0xc003638038, 0x7ffc5dd1bd48, 0x40c78f, ...)
>> /usr/local/go/src/runtime/sys_linux_amd64.s:535 +0x21
>> runtime.futexsleep(0x5b607a8, 0x0, 0x)
>> /usr/local/go/src/runtime/os_linux.go:44 +0x46
>> runtime.notesleep(0x5b607a8)
>> /usr/local/go/src/runtime/lock_futex.go:151 +0x9f
>> runtime.stopm()
>> /usr/local/go/src/runtime/proc.go:1928 +0xc0
>> runtime.exitsyscall0(0xc003638000)
>> /usr/local/go/src/runtime/proc.go:3140 +0x111
>> runtime.mcall(0x0)
>> /usr/local/go/src/runtime/asm_amd64.s:318 +0x5b
>>
>> On Wed, Aug 26, 2020 at 5:02 PM robert engels 
>> wrote:
>>
>>> That should allow your server to clean up “dead” clients. Typically you
>>> use this in conjunction with a ‘keep alive’ in the protocol.
>>>
>>> I am doubtful that a bunch of dead clients hanging around would cause a
>>> CPU spike. You really don’t have too many Go routines/connections involved
>>> (I’ve worked with 1000’s of live connections).
>>>
>>> I would look at something else… I am guessing your synchronization is
>>> incorrect and your threads are blocking, and you have a few that are
>>> spinning expecting something to happen that never will (because the source
>>> of the event is blocked on the mutex/lock).
>>>
>>>
>>>
>>> On Aug 26, 2020, at 10:09 AM, Siddhesh Divekar <
>>> siddhesh.dive...@gmail.com> wrote:
>>>
>>> Robert,
>>>
>>> I assume we can safely add these timeouts based on what we expect
>>> should be a reasonable timeout for our clients ?
>>>
>>> s.ReadTimeout = expTimeOut * time.Second
>>> s.WriteTimeout = expTimeOut * time.Second
>>>
>>> On Tue, Aug 25, 2020 at 1:14 PM Siddhesh Divekar <
>>> siddhesh.dive...@gmail.com> wrote:
>>>
 Both servers and data sources are in the cloud.
 I would not say a lot of data, it's precomputed data which shouldn't
 take that long.


 On Tue, Aug 25, 2020 at 11:25 AM Robert Engels 
 wrote:

> Are you transferring a lot of data? Are the servers non-cloud hosted?
>
> You could be encountering “tcp stalls”.
>
> On Aug 25, 2020, at 9:24 AM, Siddhesh Divekar <
> siddhesh.dive...@gmail.com> wrote:
>
> 
> Clients are over the internet.
>
> On Tue, Aug 25, 2020 at 3:25 AM Robert Engels 
> wrote:
>
>> The tcp protocol allows the connection to wait for hours. Go routines
>> stuck in wait do not burn CPU. Are the 

Re: [go-nuts] Go routines stuck in runtime_pollwait

[Siddhesh Divekar]

Right, then it looks less likely that we are blocked on a mutex.

Every 2 minutes we spin up a go routine which then in turn spins up a bunch
of go routines to collect data from big query & elastic (data collector
routines).
The 2 minutes go routine then in turn waits on waitgroup for data collector
routines to come back. So its not single go routine from our side at least.
>From backtrace we have from sigabort we see only one such data collector go
routine blocked and other 2 2 mins thread waiting on waitgroup.

I see similar issues on the internet. Kubernetes hit the following issue
which has exactly the same signature as us.

https://github.com/kubernetes/kubernetes/issues/53191

I will follow up with big query guys to see what their behavior is. If one
of the requests gets stuck on big query, what do they do with
other requests?
But in that case in our back trace we should see all other requests waiting
in their code which is not the case.



On Wed, Aug 26, 2020 at 7:44 PM Robert Engels  wrote:

> If you look at the stack trace the futex is because it is trying to
> shutdown the entire process - killing all of the M’s - probably because you
> sent the sigabort
>
> On Aug 26, 2020, at 9:41 PM, Robert Engels  wrote:
>
> 
> The big query client may be “single threaded” meaning you may need a pool
> of connections. Not sure - haven’t used the BQ library from Go.
>
> If that’s the case a single slow query will block all of your connections
> (if they are all accessing BQ). Plus there are BQ rate limits - when you
> hit those the connector may block - again blocking all clients.
>
> On Aug 26, 2020, at 8:27 PM, Siddhesh Divekar 
> wrote:
>
> 
> Robert,
>
> That's where the confusion is.
> From the backtrace we see that two go routines are blocked on the
> waitgroup.
> The go routine on which they are blocked is waiting on big query to return.
>
> On every user request we create a new go routine so they shouldn't get
> blocked because of these two.
>
> However, we do see one go routine blocked on futex. Is there a way to know
> from where it originated from ?
> When does golang use futex under the hold so that we can investigate from
> that angle.
>
> goroutine 0 [idle]:
> runtime.futex(0x5b607a8, 0x80, 0x0, 0x0, 0x0, 0x7ffc5dd1bd20, 0x437640,
> 0xc003638038, 0x7ffc5dd1bd48, 0x40c78f, ...)
> /usr/local/go/src/runtime/sys_linux_amd64.s:535 +0x21
> runtime.futexsleep(0x5b607a8, 0x0, 0x)
> /usr/local/go/src/runtime/os_linux.go:44 +0x46
> runtime.notesleep(0x5b607a8)
> /usr/local/go/src/runtime/lock_futex.go:151 +0x9f
> runtime.stopm()
> /usr/local/go/src/runtime/proc.go:1928 +0xc0
> runtime.exitsyscall0(0xc003638000)
> /usr/local/go/src/runtime/proc.go:3140 +0x111
> runtime.mcall(0x0)
> /usr/local/go/src/runtime/asm_amd64.s:318 +0x5b
>
> On Wed, Aug 26, 2020 at 5:02 PM robert engels 
> wrote:
>
>> That should allow your server to clean up “dead” clients. Typically you
>> use this in conjunction with a ‘keep alive’ in the protocol.
>>
>> I am doubtful that a bunch of dead clients hanging around would cause a
>> CPU spike. You really don’t have too many Go routines/connections involved
>> (I’ve worked with 1000’s of live connections).
>>
>> I would look at something else… I am guessing your synchronization is
>> incorrect and your threads are blocking, and you have a few that are
>> spinning expecting something to happen that never will (because the source
>> of the event is blocked on the mutex/lock).
>>
>>
>>
>> On Aug 26, 2020, at 10:09 AM, Siddhesh Divekar <
>> siddhesh.dive...@gmail.com> wrote:
>>
>> Robert,
>>
>> I assume we can safely add these timeouts based on what we expect
>> should be a reasonable timeout for our clients ?
>>
>> s.ReadTimeout = expTimeOut * time.Second
>> s.WriteTimeout = expTimeOut * time.Second
>>
>> On Tue, Aug 25, 2020 at 1:14 PM Siddhesh Divekar <
>> siddhesh.dive...@gmail.com> wrote:
>>
>>> Both servers and data sources are in the cloud.
>>> I would not say a lot of data, it's precomputed data which shouldn't
>>> take that long.
>>>
>>>
>>> On Tue, Aug 25, 2020 at 11:25 AM Robert Engels 
>>> wrote:
>>>
 Are you transferring a lot of data? Are the servers non-cloud hosted?

 You could be encountering “tcp stalls”.

 On Aug 25, 2020, at 9:24 AM, Siddhesh Divekar <
 siddhesh.dive...@gmail.com> wrote:

 
 Clients are over the internet.

 On Tue, Aug 25, 2020 at 3:25 AM Robert Engels 
 wrote:

> The tcp protocol allows the connection to wait for hours. Go routines
> stuck in wait do not burn CPU. Are the clients local or remote (over
> internet)?
>
> On Aug 24, 2020, at 10:29 PM, Siddhesh Divekar <
> siddhesh.dive...@gmail.com> wrote:
>
> 
> Robert,
>
> We will do the profiling next time we hit the issue again & see what
> is happening.
> This was the first time we saw the issue & don't want to get rid of
> 

[go-nuts] Re: some interesting ideas: reuse package keyword to declare generics

[Di gg]

> whereas to use a map type parameter,
its key and elements must also present in the declaration signarure or 
constraint definitions.

sorry, missed some words here. It should be

whereas for the official draft, ...

On Wednesday, August 26, 2020 at 1:16:49 PM UTC-4 Di gg wrote:

>
>
> https://github.com/dotaheor/unify-Go-builtin-and-custom-generics/blob/master/use-package-as-gen.md
>
> This is an alternative generic idea set, which should be Go 1 compatible.
> It tries to use the same syntax forms as builtin generics.
>
> Different from the official draft, it adopts a from-top-to-bottom pattern,
> instead of the from-bottom-to-top pattern, to describe type parameters.
> For example, given a map type parameter M, its key and element types could
> be denoted as M.key and M.element, whereas to use a map type parameter,
> its key and elements must also present in the declaration signarure or 
> constraint definitions.
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/816c221d-f65c-4c26-81d4-126d6080c5b4n%40googlegroups.com.

Re: [go-nuts] Go routines stuck in runtime_pollwait

[Robert Engels]

If you look at the stack trace the futex is because it is trying to shutdown 
the entire process - killing all of the M’s - probably because you sent the 
sigabort 

> On Aug 26, 2020, at 9:41 PM, Robert Engels  wrote:
> 
> 
> The big query client may be “single threaded” meaning you may need a pool of 
> connections. Not sure - haven’t used the BQ library from Go. 
> 
> If that’s the case a single slow query will block all of your connections (if 
> they are all accessing BQ). Plus there are BQ rate limits - when you hit 
> those the connector may block - again blocking all clients. 
> 
>>> On Aug 26, 2020, at 8:27 PM, Siddhesh Divekar  
>>> wrote:
>>> 
>> 
>> Robert,
>> 
>> That's where the confusion is.
>> From the backtrace we see that two go routines are blocked on the waitgroup.
>> The go routine on which they are blocked is waiting on big query to return.
>> 
>> On every user request we create a new go routine so they shouldn't get 
>> blocked because of these two.
>> 
>> However, we do see one go routine blocked on futex. Is there a way to know 
>> from where it originated from ?
>> When does golang use futex under the hold so that we can investigate from 
>> that angle.
>> 
>> goroutine 0 [idle]:
>> runtime.futex(0x5b607a8, 0x80, 0x0, 0x0, 0x0, 0x7ffc5dd1bd20, 0x437640, 
>> 0xc003638038, 0x7ffc5dd1bd48, 0x40c78f, ...)
>> /usr/local/go/src/runtime/sys_linux_amd64.s:535 +0x21
>> runtime.futexsleep(0x5b607a8, 0x0, 0x)
>> /usr/local/go/src/runtime/os_linux.go:44 +0x46
>> runtime.notesleep(0x5b607a8)
>> /usr/local/go/src/runtime/lock_futex.go:151 +0x9f
>> runtime.stopm()
>> /usr/local/go/src/runtime/proc.go:1928 +0xc0
>> runtime.exitsyscall0(0xc003638000)
>> /usr/local/go/src/runtime/proc.go:3140 +0x111
>> runtime.mcall(0x0)
>> /usr/local/go/src/runtime/asm_amd64.s:318 +0x5b
>> 
>>> On Wed, Aug 26, 2020 at 5:02 PM robert engels  wrote:
>>> That should allow your server to clean up “dead” clients. Typically you use 
>>> this in conjunction with a ‘keep alive’ in the protocol.
>>> 
>>> I am doubtful that a bunch of dead clients hanging around would cause a CPU 
>>> spike. You really don’t have too many Go routines/connections involved 
>>> (I’ve worked with 1000’s of live connections).
>>> 
>>> I would look at something else… I am guessing your synchronization is 
>>> incorrect and your threads are blocking, and you have a few that are 
>>> spinning expecting something to happen that never will (because the source 
>>> of the event is blocked on the mutex/lock).
>>> 
>>> 
>>> 
 On Aug 26, 2020, at 10:09 AM, Siddhesh Divekar 
  wrote:
 
 Robert,
 
 I assume we can safely add these timeouts based on what we expect
 should be a reasonable timeout for our clients ?
 
 s.ReadTimeout = expTimeOut * time.Second
 s.WriteTimeout = expTimeOut * time.Second
 
> On Tue, Aug 25, 2020 at 1:14 PM Siddhesh Divekar 
>  wrote:
> Both servers and data sources are in the cloud.
> I would not say a lot of data, it's precomputed data which shouldn't take 
> that long.
> 
> 
>> On Tue, Aug 25, 2020 at 11:25 AM Robert Engels  
>> wrote:
>> Are you transferring a lot of data? Are the servers non-cloud hosted? 
>> 
>> You could be encountering “tcp stalls”. 
>> 
 On Aug 25, 2020, at 9:24 AM, Siddhesh Divekar 
  wrote:
 
>>> 
>>> Clients are over the internet.
>>> 
 On Tue, Aug 25, 2020 at 3:25 AM Robert Engels  
 wrote:
 The tcp protocol allows the connection to wait for hours. Go routines 
 stuck in wait do not burn CPU. Are the clients local or remote (over 
 internet)?
 
>> On Aug 24, 2020, at 10:29 PM, Siddhesh Divekar 
>>  wrote:
>> 
> 
> Robert,
> 
> We will do the profiling next time we hit the issue again & see what 
> is happening.
> This was the first time we saw the issue & don't want to get rid of 
> http2 advantages without making sure it's the actual culprit.
> 
> Do you think in the meanwhile we should do what the discussion below 
> suggests anyways ?
> https://stackoverflow.com/questions/42238695/goroutine-in-io-wait-state-for-long-time
> 
> 
>> On Mon, Aug 24, 2020 at 5:37 PM Robert Engels 
>>  wrote:
>> I think it is too hard to tell with the limited information. It 
>> could be exhausted connections or it could be thrashing (the claim 
>> of high cpu)
>> 
>> I think you want to run profiling capture prior to hitting the stick 
>> state - you should be able to detect what is happening. 
>> 
>> If the referenced issue is related I would assume you should be able 
>> to connect by forcing http/1. 
>> 
>> You can also try disabling http/2 and 

Re: [go-nuts] Go routines stuck in runtime_pollwait

[Robert Engels]

The big query client may be “single threaded” meaning you may need a pool of 
connections. Not sure - haven’t used the BQ library from Go. 

If that’s the case a single slow query will block all of your connections (if 
they are all accessing BQ). Plus there are BQ rate limits - when you hit those 
the connector may block - again blocking all clients. 

> On Aug 26, 2020, at 8:27 PM, Siddhesh Divekar  
> wrote:
> 
> 
> Robert,
> 
> That's where the confusion is.
> From the backtrace we see that two go routines are blocked on the waitgroup.
> The go routine on which they are blocked is waiting on big query to return.
> 
> On every user request we create a new go routine so they shouldn't get 
> blocked because of these two.
> 
> However, we do see one go routine blocked on futex. Is there a way to know 
> from where it originated from ?
> When does golang use futex under the hold so that we can investigate from 
> that angle.
> 
> goroutine 0 [idle]:
> runtime.futex(0x5b607a8, 0x80, 0x0, 0x0, 0x0, 0x7ffc5dd1bd20, 0x437640, 
> 0xc003638038, 0x7ffc5dd1bd48, 0x40c78f, ...)
> /usr/local/go/src/runtime/sys_linux_amd64.s:535 +0x21
> runtime.futexsleep(0x5b607a8, 0x0, 0x)
> /usr/local/go/src/runtime/os_linux.go:44 +0x46
> runtime.notesleep(0x5b607a8)
> /usr/local/go/src/runtime/lock_futex.go:151 +0x9f
> runtime.stopm()
> /usr/local/go/src/runtime/proc.go:1928 +0xc0
> runtime.exitsyscall0(0xc003638000)
> /usr/local/go/src/runtime/proc.go:3140 +0x111
> runtime.mcall(0x0)
> /usr/local/go/src/runtime/asm_amd64.s:318 +0x5b
> 
> On Wed, Aug 26, 2020 at 5:02 PM robert engels  wrote:
>> That should allow your server to clean up “dead” clients. Typically you use 
>> this in conjunction with a ‘keep alive’ in the protocol.
>> 
>> I am doubtful that a bunch of dead clients hanging around would cause a CPU 
>> spike. You really don’t have too many Go routines/connections involved (I’ve 
>> worked with 1000’s of live connections).
>> 
>> I would look at something else… I am guessing your synchronization is 
>> incorrect and your threads are blocking, and you have a few that are 
>> spinning expecting something to happen that never will (because the source 
>> of the event is blocked on the mutex/lock).
>> 
>> 
>> 
>>> On Aug 26, 2020, at 10:09 AM, Siddhesh Divekar  
>>> wrote:
>>> 
>>> Robert,
>>> 
>>> I assume we can safely add these timeouts based on what we expect
>>> should be a reasonable timeout for our clients ?
>>> 
>>> s.ReadTimeout = expTimeOut * time.Second
>>> s.WriteTimeout = expTimeOut * time.Second
>>> 
>>> On Tue, Aug 25, 2020 at 1:14 PM Siddhesh Divekar 
>>>  wrote:
 Both servers and data sources are in the cloud.
 I would not say a lot of data, it's precomputed data which shouldn't take 
 that long.
 
 
 On Tue, Aug 25, 2020 at 11:25 AM Robert Engels  
 wrote:
> Are you transferring a lot of data? Are the servers non-cloud hosted? 
> 
> You could be encountering “tcp stalls”. 
> 
>> On Aug 25, 2020, at 9:24 AM, Siddhesh Divekar 
>>  wrote:
>> 
>> 
>> Clients are over the internet.
>> 
>> On Tue, Aug 25, 2020 at 3:25 AM Robert Engels  
>> wrote:
>>> The tcp protocol allows the connection to wait for hours. Go routines 
>>> stuck in wait do not burn CPU. Are the clients local or remote (over 
>>> internet)?
>>> 
 On Aug 24, 2020, at 10:29 PM, Siddhesh Divekar 
  wrote:
 
 
 Robert,
 
 We will do the profiling next time we hit the issue again & see what 
 is happening.
 This was the first time we saw the issue & don't want to get rid of 
 http2 advantages without making sure it's the actual culprit.
 
 Do you think in the meanwhile we should do what the discussion below 
 suggests anyways ?
 https://stackoverflow.com/questions/42238695/goroutine-in-io-wait-state-for-long-time
 
 
 On Mon, Aug 24, 2020 at 5:37 PM Robert Engels  
 wrote:
> I think it is too hard to tell with the limited information. It could 
> be exhausted connections or it could be thrashing (the claim of high 
> cpu)
> 
> I think you want to run profiling capture prior to hitting the stick 
> state - you should be able to detect what is happening. 
> 
> If the referenced issue is related I would assume you should be able 
> to connect by forcing http/1. 
> 
> You can also try disabling http/2 and see if your issue goes away. 
> 
> On Aug 24, 2020, at 6:15 PM, Siddhesh Divekar 
>  wrote:
> 
>> Hi Robert,
>> 
>> Sorry I missed your earlier response.
>> 
>> From what we saw our UI was blocked and since everything was 
>> unresponsive
>> we had to recover the system by sending 

Re: [go-nuts] Go routines stuck in runtime_pollwait

[Siddhesh Divekar]

Robert,

That's where the confusion is.
>From the backtrace we see that two go routines are blocked on the waitgroup.
The go routine on which they are blocked is waiting on big query to return.

On every user request we create a new go routine so they shouldn't get
blocked because of these two.

However, we do see one go routine blocked on futex. Is there a way to know
from where it originated from ?
When does golang use futex under the hold so that we can investigate from
that angle.

goroutine 0 [idle]:
runtime.futex(0x5b607a8, 0x80, 0x0, 0x0, 0x0, 0x7ffc5dd1bd20, 0x437640,
0xc003638038, 0x7ffc5dd1bd48, 0x40c78f, ...)
/usr/local/go/src/runtime/sys_linux_amd64.s:535 +0x21
runtime.futexsleep(0x5b607a8, 0x0, 0x)
/usr/local/go/src/runtime/os_linux.go:44 +0x46
runtime.notesleep(0x5b607a8)
/usr/local/go/src/runtime/lock_futex.go:151 +0x9f
runtime.stopm()
/usr/local/go/src/runtime/proc.go:1928 +0xc0
runtime.exitsyscall0(0xc003638000)
/usr/local/go/src/runtime/proc.go:3140 +0x111
runtime.mcall(0x0)
/usr/local/go/src/runtime/asm_amd64.s:318 +0x5b

On Wed, Aug 26, 2020 at 5:02 PM robert engels  wrote:

> That should allow your server to clean up “dead” clients. Typically you
> use this in conjunction with a ‘keep alive’ in the protocol.
>
> I am doubtful that a bunch of dead clients hanging around would cause a
> CPU spike. You really don’t have too many Go routines/connections involved
> (I’ve worked with 1000’s of live connections).
>
> I would look at something else… I am guessing your synchronization is
> incorrect and your threads are blocking, and you have a few that are
> spinning expecting something to happen that never will (because the source
> of the event is blocked on the mutex/lock).
>
>
>
> On Aug 26, 2020, at 10:09 AM, Siddhesh Divekar 
> wrote:
>
> Robert,
>
> I assume we can safely add these timeouts based on what we expect
> should be a reasonable timeout for our clients ?
>
> s.ReadTimeout = expTimeOut * time.Second
> s.WriteTimeout = expTimeOut * time.Second
>
> On Tue, Aug 25, 2020 at 1:14 PM Siddhesh Divekar <
> siddhesh.dive...@gmail.com> wrote:
>
>> Both servers and data sources are in the cloud.
>> I would not say a lot of data, it's precomputed data which shouldn't take
>> that long.
>>
>>
>> On Tue, Aug 25, 2020 at 11:25 AM Robert Engels 
>> wrote:
>>
>>> Are you transferring a lot of data? Are the servers non-cloud hosted?
>>>
>>> You could be encountering “tcp stalls”.
>>>
>>> On Aug 25, 2020, at 9:24 AM, Siddhesh Divekar <
>>> siddhesh.dive...@gmail.com> wrote:
>>>
>>> 
>>> Clients are over the internet.
>>>
>>> On Tue, Aug 25, 2020 at 3:25 AM Robert Engels 
>>> wrote:
>>>
 The tcp protocol allows the connection to wait for hours. Go routines
 stuck in wait do not burn CPU. Are the clients local or remote (over
 internet)?

 On Aug 24, 2020, at 10:29 PM, Siddhesh Divekar <
 siddhesh.dive...@gmail.com> wrote:

 
 Robert,

 We will do the profiling next time we hit the issue again & see what is
 happening.
 This was the first time we saw the issue & don't want to get rid of
 http2 advantages without making sure it's the actual culprit.

 Do you think in the meanwhile we should do what the discussion below
 suggests anyways ?

 https://stackoverflow.com/questions/42238695/goroutine-in-io-wait-state-for-long-time


 On Mon, Aug 24, 2020 at 5:37 PM Robert Engels 
 wrote:

> I think it is too hard to tell with the limited information. It could
> be exhausted connections or it could be thrashing (the claim of high cpu)
>
> I think you want to run profiling capture prior to hitting the stick
> state - you should be able to detect what is happening.
>
> If the referenced issue is related I would assume you should be able
> to connect by forcing http/1.
>
> You can also try disabling http/2 and see if your issue goes away.
>
> On Aug 24, 2020, at 6:15 PM, Siddhesh Divekar <
> siddhesh.dive...@gmail.com> wrote:
>
> Hi Robert,
>
> Sorry I missed your earlier response.
>
> From what we saw our UI was blocked and since everything was
> unresponsive
> we had to recover the system by sending sig abort.
>
> On Mon, Aug 24, 2020 at 4:11 PM Siddhesh Divekar <
> siddhesh.dive...@gmail.com> wrote:
>
>> Looking at the no. of go routines we have does this apply to this
>> issue ?
>> https://github.com/golang/go/issues/27044
>>
>> On Mon, Aug 24, 2020 at 12:54 PM Robert Engels 
>> wrote:
>>
>>> Go routines in a waiting state should not be consuming CPU. Are you
>>> certain they are not in constant transition from waiting to processing -
>>> this could show up as high CPU usage while everything looks blocks.
>>>
>>> I would use pprof - github.com/robaho/goanalyzer might be of
>>> assistance here to 

Re: [go-nuts] [ANN] CGo-free sqlite database/sql driver 1.4.0 for linux/amd64 released

[Mandolyte]

A couple of questions:

   - What is the state of Windows/MacOS?
   - How about Windows Subsystem for Linux?

Thanks!
On Wednesday, August 26, 2020 at 6:17:58 PM UTC-4 kortschak wrote:

> On Wed, 2020-08-26 at 23:50 +0200, Jan Mercl wrote:
> > From the change log (
> > https://godoc.org/modernc.org/sqlite#hdr-Changelog)
> > 
> > 2020-08-26 v1.4.0:
> > 
> > First stable release for linux/amd64. The database/sql driver and its
> > tests are CGo free. Tests of the translated sqlite3.c library still
> > require CGo.
> > 
> > $ make full
> > 
> > ...
> > 
> > SQLite 2020-08-14 13:23:32
> > fca8dc8b578f215a969cd899336378966156154710873e68b3d9ac5881b0ff3f
> > 0 errors out of 928271 tests on 3900x Linux 64-bit little-endian
> > WARNING: Multi-threaded tests skipped: Linked against a non-
> > threadsafe Tcl build
> > All memory allocations freed - no leaks
> > Maximum memory usage: 9156360 bytes
> > Current memory usage: 0 bytes
> > Number of malloc() : -1 calls
> > --- PASS: TestTclTest (1785.04s)
> > PASS
> > ok modernc.org/sqlite 1785.041s
> > $
> > 
>
> This is just what I have been looking for for a little toy I'm writing.
>
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/033fe992-bcce-4870-bf52-4b7e54ca1caen%40googlegroups.com.

Re: [go-nuts] Go routines stuck in runtime_pollwait

[robert engels]

That should allow your server to clean up “dead” clients. Typically you use 
this in conjunction with a ‘keep alive’ in the protocol.

I am doubtful that a bunch of dead clients hanging around would cause a CPU 
spike. You really don’t have too many Go routines/connections involved (I’ve 
worked with 1000’s of live connections).

I would look at something else… I am guessing your synchronization is incorrect 
and your threads are blocking, and you have a few that are spinning expecting 
something to happen that never will (because the source of the event is blocked 
on the mutex/lock).



> On Aug 26, 2020, at 10:09 AM, Siddhesh Divekar  
> wrote:
> 
> Robert,
> 
> I assume we can safely add these timeouts based on what we expect
> should be a reasonable timeout for our clients ?
> 
> s.ReadTimeout = expTimeOut * time.Second
> s.WriteTimeout = expTimeOut * time.Second
> 
> On Tue, Aug 25, 2020 at 1:14 PM Siddhesh Divekar  > wrote:
> Both servers and data sources are in the cloud.
> I would not say a lot of data, it's precomputed data which shouldn't take 
> that long.
> 
> 
> On Tue, Aug 25, 2020 at 11:25 AM Robert Engels  > wrote:
> Are you transferring a lot of data? Are the servers non-cloud hosted? 
> 
> You could be encountering “tcp stalls”. 
> 
>> On Aug 25, 2020, at 9:24 AM, Siddhesh Divekar > > wrote:
>> 
>> 
>> Clients are over the internet.
>> 
>> On Tue, Aug 25, 2020 at 3:25 AM Robert Engels > > wrote:
>> The tcp protocol allows the connection to wait for hours. Go routines stuck 
>> in wait do not burn CPU. Are the clients local or remote (over internet)?
>> 
>>> On Aug 24, 2020, at 10:29 PM, Siddhesh Divekar >> > wrote:
>>> 
>>> 
>>> Robert,
>>> 
>>> We will do the profiling next time we hit the issue again & see what is 
>>> happening.
>>> This was the first time we saw the issue & don't want to get rid of http2 
>>> advantages without making sure it's the actual culprit.
>>> 
>>> Do you think in the meanwhile we should do what the discussion below 
>>> suggests anyways ?
>>> https://stackoverflow.com/questions/42238695/goroutine-in-io-wait-state-for-long-time
>>>  
>>> 
>>> 
>>> 
>>> On Mon, Aug 24, 2020 at 5:37 PM Robert Engels >> > wrote:
>>> I think it is too hard to tell with the limited information. It could be 
>>> exhausted connections or it could be thrashing (the claim of high cpu)
>>> 
>>> I think you want to run profiling capture prior to hitting the stick state 
>>> - you should be able to detect what is happening. 
>>> 
>>> If the referenced issue is related I would assume you should be able to 
>>> connect by forcing http/1. 
>>> 
>>> You can also try disabling http/2 and see if your issue goes away. 
>>> 
>>> On Aug 24, 2020, at 6:15 PM, Siddhesh Divekar >> > wrote:
>>> 
 Hi Robert,
 
 Sorry I missed your earlier response.
 
 From what we saw our UI was blocked and since everything was unresponsive
 we had to recover the system by sending sig abort. 
 
 On Mon, Aug 24, 2020 at 4:11 PM Siddhesh Divekar 
 mailto:siddhesh.dive...@gmail.com>> wrote:
 Looking at the no. of go routines we have does this apply to this issue ?
 https://github.com/golang/go/issues/27044 
 
 
 On Mon, Aug 24, 2020 at 12:54 PM Robert Engels >>> > wrote:
 Go routines in a waiting state should not be consuming CPU. Are you 
 certain they are not in constant transition from waiting to processing - 
 this could show up as high CPU usage while everything looks blocks. 
 
 I would use pprof - github.com/robaho/goanalyzer 
  might be of assistance here to see 
 the actual work being done. 
 
> On Aug 24, 2020, at 9:10 AM, Siddhesh Divekar  > wrote:
> 
> 
> Hi Ian,
> 
> Thanks for replying. 
> 
> We have a go server running which handles user requests & collects data 
> from various sources like gcp's cloud sql and big query.
> We are using shopify's sarama library to do kafka operations.
> 
> There are seeing lots of go routines in waiting state for several 
> minutes. 
> Over the period of time around 587 goroutines have been spun up.
> 
> We see that two go routines are stuck on gcp big query and we are using 
> wait groups there.
> However, it's not clear why that would cause all other go routines to get 
> hung & make cpu go high.
> 
> goroutine 3332131 [semacquire, 79 minutes]:
> sync.runtime_Semacquire(0xc001c4fcf8)
> /usr/local/go/src/runtime/sema.go:56 

Re: [go-nuts] [ANN] CGo-free sqlite database/sql driver 1.4.0 for linux/amd64 released

['Dan Kortschak' via golang-nuts]

On Wed, 2020-08-26 at 23:50 +0200, Jan Mercl wrote:
> From the change log (
> https://godoc.org/modernc.org/sqlite#hdr-Changelog)
> 
> 2020-08-26 v1.4.0:
> 
> First stable release for linux/amd64. The database/sql driver and its
> tests are CGo free. Tests of the translated sqlite3.c library still
> require CGo.
> 
> $ make full
> 
> ...
> 
> SQLite 2020-08-14 13:23:32
> fca8dc8b578f215a969cd899336378966156154710873e68b3d9ac5881b0ff3f
> 0 errors out of 928271 tests on 3900x Linux 64-bit little-endian
> WARNING: Multi-threaded tests skipped: Linked against a non-
> threadsafe Tcl build
> All memory allocations freed - no leaks
> Maximum memory usage: 9156360 bytes
> Current memory usage: 0 bytes
> Number of malloc()  : -1 calls
> --- PASS: TestTclTest (1785.04s)
> PASS
> ok  modernc.org/sqlite  1785.041s
> $
> 

This is just what I have been looking for for a little toy I'm writing.


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/99c1e8c1aeb3c3253b63461befec3d887de2c559.camel%40kortschak.io.

[go-nuts] [ANN] CGo-free sqlite database/sql driver 1.4.0 for linux/amd64 released

[Jan Mercl]

>From the change log (https://godoc.org/modernc.org/sqlite#hdr-Changelog)

2020-08-26 v1.4.0:

First stable release for linux/amd64. The database/sql driver and its tests
are CGo free. Tests of the translated sqlite3.c library still require CGo.

$ make full

...

SQLite 2020-08-14 13:23:32
fca8dc8b578f215a969cd899336378966156154710873e68b3d9ac5881b0ff3f
0 errors out of 928271 tests on 3900x Linux 64-bit little-endian
WARNING: Multi-threaded tests skipped: Linked against a non-threadsafe Tcl
build
All memory allocations freed - no leaks
Maximum memory usage: 9156360 bytes
Current memory usage: 0 bytes
Number of malloc()  : -1 calls
--- PASS: TestTclTest (1785.04s)
PASS
ok  modernc.org/sqlite  1785.041s
$

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-XnjDzZnc31UOBn-gHoueT10FrvLCyZh9c8VK7K8ObKjg%40mail.gmail.com.

[go-nuts] Proposal: env variable defaults

[Liam]

Some users have requested a way to turn off async preemption without having 
to set an environment variable at runtime.

If you'd benefit from building defaults for GODEBUG and other environment 
variables into Go programs, please comment here:

https://github.com/golang/go/issues/40870

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9dd24c04-4c1c-42ab-9d38-f01e5eac052dn%40googlegroups.com.

Re: [go-nuts] Naming environment variables

[Siddhesh Divekar]

Hi Ian,

Got it !

Thanks.

On Wed, Aug 26, 2020 at 9:09 AM Ian Lance Taylor  wrote:

> On Wed, Aug 26, 2020 at 8:03 AM Siddhesh Divekar
>  wrote:
> >
> > What is the convention to name an environment variable if the program is
> going to set it and use it.
> > I have seen both ABC_DEF & AbcDef forms of it.
>
> Do you mean the name used for the environment variable, or the name
> used in the Go program?
>
> Most environment variables use names in all caps with underscores, so
> ABC_DEF.
>
> Most Go variables use mixed caps, so AbcDef.
>
> Ian
>


-- 
-Siddhesh.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMjfk%2BjcS5q7ahpgw%3D40vnvtOtmPNqLXQnQRpEb5-v96X5uqpQ%40mail.gmail.com.

[go-nuts] Re: instruction gen in amd64, it iseems not the best choice?

[moehrmann via golang-nuts]

As far as I am aware:

A LEA with a scale of 3 does not exist on amd64. Scale can be 1,2,4,8.

A LEA with 3 arguments LEAQ 4(AX)(AX*2) on many modern amd64 compatible 
machines will use 3 cycles instead of 2 for two simpler LEA.
The newest generation of Intel CPUs seems to have gotten better again 
avoiding slow LEA.

https://github.com/golang/go/issues/21735
https://github.com/golang/go/issues/31900

On Wednesday, August 26, 2020 at 5:04:15 AM UTC+2, xie cui wrote:
>
> function:
> func test3(a int) int {
>   return a * 3 + 4
> }
>
> go version go1.13.5 darwin/amd64
> generate instructions:
>   LEAQ(AX)(AX*2), AX
>   LEAQ4(AX), AX
>
> As far as i known，there a better choice
>  LEAQ4(AX*3), AX
>
> Can it be optimized?
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0d638194-eaf0-4b99-b66e-c831d8491470o%40googlegroups.com.

[go-nuts] some interesting ideas: reuse package keyword to declare generics

[Di gg]

https://github.com/dotaheor/unify-Go-builtin-and-custom-generics/blob/master/use-package-as-gen.md

This is an alternative generic idea set, which should be Go 1 compatible.
It tries to use the same syntax forms as builtin generics.

Different from the official draft, it adopts a from-top-to-bottom pattern,
instead of the from-bottom-to-top pattern, to describe type parameters.
For example, given a map type parameter M, its key and element types could
be denoted as M.key and M.element, whereas to use a map type parameter,
its key and elements must also present in the declaration signarure or 
constraint definitions.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/facd3bf8-1f62-4b6e-b518-28f33738cb3an%40googlegroups.com.

Re: [go-nuts] Dynamic composition of interfaces at runtime?

[cpu...@gmail.com]

Great post, thank you! Found you Wrap method looks exactly like my decorate 
:). 

While not entirely satisfying it does solve the problem and the set of 
optional methods in my case is always below 5 so the effort is manageable. 
Since the optional interfaces are really narrow (always 1 method) I guess I 
can proceed with this approach...

Kind regards,
Andi

On Wednesday, August 26, 2020 at 5:59:13 PM UTC+2 axel.wa...@googlemail.com 
wrote:

> Hi,
>
> no, there isn't really a solution to this. I've blogged about this:
>
> https://blog.merovius.de/2017/07/30/the-trouble-with-optional-interfaces.html
> A combination of generics and embedding can help. So, you can do
>
> type Wrapper[T] struct {
> T
> otherFields
> }
>
> func (w *Wrapper) SomeNewMethod() {
> }
>
> But even then, you need to know the static type of what you're wrapping 
> (so http Middleware, for example, couldn't use this).
>
> I'm also not super sure if it's a good idea to do this even if you could. 
> An interface might contain multiple, interdependent methods. As an example, 
> `http.ResponseWriter` implicitly calls `WriteHeader` the first time you 
> call `Write`. So, if you wrap a `ResponseWriter` and overwrite 
> `WriteHeader`, that overwritten method has to be called explicitly (the 
> underlying `ResponseWriter` will call its own `WriteHeader`). So if you 
> don't know what the methods of the wrapped type are and do, you might 
> introduce very hard to find bugs.
>
> On Wed, Aug 26, 2020 at 5:49 PM cpu...@gmail.com  wrote:
>
>> Hi All,
>>
>> using interfaces for behavioural testing seems a common pattern in go:
>>
>> if typed, hasCapability := d.(Capability); hasCapability...
>>
>> I have the requirement to dynamically compose interfaces at runtime, i.e. 
>> I cannot know upfront which set of interfaces a resulting type will support:
>>
>> type resultingType interface {
>> basicCapability
>> ...any combination of additional capabilities
>> }
>>
>> If there is only a single additional/optional capability to implement 
>> that is simple to solve, e.g. by implementing a wrapping struct that embeds 
>> the basic capability and adds an additional capability. Applying this 
>> pattern across multiple layers (stack of wrapping structs does not work as 
>> the embedded interfaces don't bubble up).
>>
>> However, the number of additional capabilities that a type might have to 
>> support could be bigger (think of physical meters which could supply power, 
>> energy, currents, frequency etc).
>>
>> I'm solved this by using go:generate which is fed the basic and set of 
>> optional types and generates additional types for any _combination_ of 
>> additional types, an example is attached (and source at 
>> https://github.com/andig/evcc/pull/310/files#diff-fa40c05651b4682eb25a198f8a4a98f0).
>>  
>> This is similar to the "old" pattern of simulation generics via generated 
>> code.
>>
>> I'm wondering if using a pattern of dynamic composition is sound, if the 
>> the go:generate approach is a good one or if there are better ways?
>>
>> Kind regards,
>> Andi
>>
>> -- 
>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/217cee40-1e00-442d-a4d2-7d4a37e41544n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/bacb1b26-daf2-49b3-8d56-e9530803e6f4n%40googlegroups.com.

Re: [go-nuts] Naming environment variables

[Ian Lance Taylor]

On Wed, Aug 26, 2020 at 8:03 AM Siddhesh Divekar
 wrote:
>
> What is the convention to name an environment variable if the program is 
> going to set it and use it.
> I have seen both ABC_DEF & AbcDef forms of it.

Do you mean the name used for the environment variable, or the name
used in the Go program?

Most environment variables use names in all caps with underscores, so ABC_DEF.

Most Go variables use mixed caps, so AbcDef.

Ian

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXX36wGFaVyts-SekdQGyJ0ZoR4VPAyMnVMONnyXZnO6w%40mail.gmail.com.

Re: [go-nuts] Dynamic composition of interfaces at runtime?

['Axel Wagner' via golang-nuts]

Hi,

no, there isn't really a solution to this. I've blogged about this:
https://blog.merovius.de/2017/07/30/the-trouble-with-optional-interfaces.html
A combination of generics and embedding can help. So, you can do

type Wrapper[T] struct {
T
otherFields
}

func (w *Wrapper) SomeNewMethod() {
}

But even then, you need to know the static type of what you're wrapping (so
http Middleware, for example, couldn't use this).

I'm also not super sure if it's a good idea to do this even if you could.
An interface might contain multiple, interdependent methods. As an example,
`http.ResponseWriter` implicitly calls `WriteHeader` the first time you
call `Write`. So, if you wrap a `ResponseWriter` and overwrite
`WriteHeader`, that overwritten method has to be called explicitly (the
underlying `ResponseWriter` will call its own `WriteHeader`). So if you
don't know what the methods of the wrapped type are and do, you might
introduce very hard to find bugs.

On Wed, Aug 26, 2020 at 5:49 PM cpu...@gmail.com  wrote:

> Hi All,
>
> using interfaces for behavioural testing seems a common pattern in go:
>
> if typed, hasCapability := d.(Capability); hasCapability...
>
> I have the requirement to dynamically compose interfaces at runtime, i.e.
> I cannot know upfront which set of interfaces a resulting type will support:
>
> type resultingType interface {
> basicCapability
> ...any combination of additional capabilities
> }
>
> If there is only a single additional/optional capability to implement that
> is simple to solve, e.g. by implementing a wrapping struct that embeds the
> basic capability and adds an additional capability. Applying this pattern
> across multiple layers (stack of wrapping structs does not work as the
> embedded interfaces don't bubble up).
>
> However, the number of additional capabilities that a type might have to
> support could be bigger (think of physical meters which could supply power,
> energy, currents, frequency etc).
>
> I'm solved this by using go:generate which is fed the basic and set of
> optional types and generates additional types for any _combination_ of
> additional types, an example is attached (and source at
> https://github.com/andig/evcc/pull/310/files#diff-fa40c05651b4682eb25a198f8a4a98f0).
> This is similar to the "old" pattern of simulation generics via generated
> code.
>
> I'm wondering if using a pattern of dynamic composition is sound, if the
> the go:generate approach is a good one or if there are better ways?
>
> Kind regards,
> Andi
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/217cee40-1e00-442d-a4d2-7d4a37e41544n%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEQq%2BErDOGbX5jD1PrnZQdrYut_E6zajRpYYbM3NiBe1g%40mail.gmail.com.

Re: [go-nuts] Go routines stuck in runtime_pollwait

[Siddhesh Divekar]

Robert,

I assume we can safely add these timeouts based on what we expect
should be a reasonable timeout for our clients ?

s.ReadTimeout = expTimeOut * time.Second
s.WriteTimeout = expTimeOut * time.Second

On Tue, Aug 25, 2020 at 1:14 PM Siddhesh Divekar 
wrote:

> Both servers and data sources are in the cloud.
> I would not say a lot of data, it's precomputed data which shouldn't take
> that long.
>
>
> On Tue, Aug 25, 2020 at 11:25 AM Robert Engels 
> wrote:
>
>> Are you transferring a lot of data? Are the servers non-cloud hosted?
>>
>> You could be encountering “tcp stalls”.
>>
>> On Aug 25, 2020, at 9:24 AM, Siddhesh Divekar 
>> wrote:
>>
>> 
>> Clients are over the internet.
>>
>> On Tue, Aug 25, 2020 at 3:25 AM Robert Engels 
>> wrote:
>>
>>> The tcp protocol allows the connection to wait for hours. Go routines
>>> stuck in wait do not burn CPU. Are the clients local or remote (over
>>> internet)?
>>>
>>> On Aug 24, 2020, at 10:29 PM, Siddhesh Divekar <
>>> siddhesh.dive...@gmail.com> wrote:
>>>
>>> 
>>> Robert,
>>>
>>> We will do the profiling next time we hit the issue again & see what is
>>> happening.
>>> This was the first time we saw the issue & don't want to get rid of
>>> http2 advantages without making sure it's the actual culprit.
>>>
>>> Do you think in the meanwhile we should do what the discussion below
>>> suggests anyways ?
>>>
>>> https://stackoverflow.com/questions/42238695/goroutine-in-io-wait-state-for-long-time
>>>
>>>
>>> On Mon, Aug 24, 2020 at 5:37 PM Robert Engels 
>>> wrote:
>>>
 I think it is too hard to tell with the limited information. It could
 be exhausted connections or it could be thrashing (the claim of high cpu)

 I think you want to run profiling capture prior to hitting the stick
 state - you should be able to detect what is happening.

 If the referenced issue is related I would assume you should be able to
 connect by forcing http/1.

 You can also try disabling http/2 and see if your issue goes away.

 On Aug 24, 2020, at 6:15 PM, Siddhesh Divekar <
 siddhesh.dive...@gmail.com> wrote:

 Hi Robert,

 Sorry I missed your earlier response.

 From what we saw our UI was blocked and since everything was
 unresponsive
 we had to recover the system by sending sig abort.

 On Mon, Aug 24, 2020 at 4:11 PM Siddhesh Divekar <
 siddhesh.dive...@gmail.com> wrote:

> Looking at the no. of go routines we have does this apply to this
> issue ?
> https://github.com/golang/go/issues/27044
>
> On Mon, Aug 24, 2020 at 12:54 PM Robert Engels 
> wrote:
>
>> Go routines in a waiting state should not be consuming CPU. Are you
>> certain they are not in constant transition from waiting to processing -
>> this could show up as high CPU usage while everything looks blocks.
>>
>> I would use pprof - github.com/robaho/goanalyzer might be of
>> assistance here to see the actual work being done.
>>
>> On Aug 24, 2020, at 9:10 AM, Siddhesh Divekar <
>> siddhesh.dive...@gmail.com> wrote:
>>
>> 
>> Hi Ian,
>>
>> Thanks for replying.
>>
>> We have a go server running which handles user requests & collects
>> data from various sources like gcp's cloud sql and big query.
>> We are using shopify's sarama library to do kafka operations.
>>
>> There are seeing lots of go routines in waiting state for several
>> minutes.
>> Over the period of time around 587 goroutines have been spun up.
>>
>> We see that two go routines are stuck on gcp big query and we are
>> using wait groups there.
>> However, it's not clear why that would cause all other go routines to
>> get hung & make cpu go high.
>>
>> goroutine 3332131 [semacquire, 79 minutes]:
>> sync.runtime_Semacquire(0xc001c4fcf8)
>> /usr/local/go/src/runtime/sema.go:56 +0x42
>> sync.(*WaitGroup).Wait(0xc001c4fcf0)
>> /usr/local/go/src/sync/waitgroup.go:130 +0x64
>>
>> git.fusion.io/fusionio/fusion/controller.git/stats.(*InsMgr).runParallelQuery(0xc001b54d40,
>> 0xc002912c00, 0x330e1b0, 0xf, 0xc002912cf0, 0x3)
>> /builds/fusionio/fusion/controller/stats/ins_mgr.go:488 +0x1d7
>>
>> git.fusion.io/fusionio/fusion/controller.git/stats.(*InsMgr).GetMainUi(0xc001b54d40,
>> 0xc002912db8, 0xc001870e68, 0x746121, 0xc0010fcaf8, 0x17)
>> /builds/fusionio/fusion/controller/stats/ins_mgr.go:567 +0xa0d
>>
>> git.fusion.io/fusionio/fusion/controller.git/stats.(*Prefetcher).fetchMainUiTeamInterval(0xc001b56780,
>> 0xc002356810, 0x24, 0x32f7b78, 0x5)
>> /builds/fusionio/fusion/controller/stats/prefetcher.go:77
>> +0xf2
>> created by
>> git.fusion.io/fusionio/fusion/controller.git/stats.(*Prefetcher).prefetchStats
>> /builds/fusionio/fusion/controller/stats/prefetcher.go:100
>> +0xd8
>>

[go-nuts] Naming environment variables

[Siddhesh Divekar]

Hi,

What is the convention to name an environment variable if the program is
going to set it and use it.
I have seen both ABC_DEF & AbcDef forms of it.

-- 
-Siddhesh.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAMjfk%2BgifGzE7oAsSSAEDmm9bSfPF0ZJrTQdDg4hiTR%2ByH93ZQ%40mail.gmail.com.

Re: [go-nuts] [ generics] Moving forward with the generics design draft

['Alan Donovan' via golang-nuts]

On Wed, 26 Aug 2020 at 04:31, Denis Cheremisov 
wrote:

> > possibility of using angle brackets
>
> Please stop
>
>- call these operator signs “brackets”
>- pretending they are good in a role of brackets — they are not
>- spreading this nonsense from C syntax family of languages to saner
>once — yes, you heard it right. C is known for its chaotic development and
>lack of careful planning.
>- thinking yet another strange workaround is a good thing
>
>
On terminology:
US: [brackets], (parens).
UK: (brackets), [square brackets],
I'm sure other locales have their own equally confusing names for these
things, but the Go team is based in the US, so you can't fault them for
using that dialect.

To the rest of your points, I will only say: arguments are more persuasive
than insults.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAPVWWDXQ-XKVorQN8guSkjB-ah%3DDEEK7R--7sD6hTP3jdWRU8A%40mail.gmail.com.

Re: [go-nuts] [ generics] Moving forward with the generics design draft

[Denis Cheremisov]

> possibility of using angle brackets

Please stop 

   - call these operator signs “brackets”
   - pretending they are good in a role of brackets — they are not
   - spreading this nonsense from C syntax family of languages to saner 
   once — yes, you heard it right. C is known for its chaotic development and 
   lack of careful planning.
   - thinking yet another strange workaround is a good thing


среда, 26 августа 2020 г. в 00:38:00 UTC+3, Kaveh Shahbazian: 

> I am excited about sum-types as much as generics themselves. Also, it's 
> nice that any is a keyword restricted to be used inside the type parameter 
> declaration as a type constraint.
>
> Very nice!
>
> ---
>
> P.S.
> Of-course now the proposal seems to go with brackets. Nevertheless, I 
> wrote this comment 
>  on 
> the possibility of using angle brackets for the type parameter declaration. 
> Maybe that way there are more symbols in the language. But they will be 
> less overloaded with (completely) different semantics - assuming it's a 
> practical approach.
>
> On Tuesday, August 25, 2020 at 12:35:33 AM UTC+2 Ian Lance Taylor wrote:
>
>> On Thu, Aug 20, 2020 at 9:54 PM Ian Lance Taylor  
>> wrote: 
>> > 
>> > Our intent here is that "any" will be available for all code. Yes, we 
>> > wouldn't do it if it weren't for its use as a type constraint. But if 
>> > we are going to do it for type constraints, there seems to be little 
>> > benefit to restricting it to only work as a type constraint. 
>> > 
>> > This is not, of course, a new idea, even in the absence of generics. 
>> > For example, https://golang.org/issue/33232. (My comment there was 
>> > that we would use interface{} less if we had generics, but of course 
>> > when we require type constraints then we actually wind up using it 
>> > somewhat more.) 
>>
>> I've seen objections that a language change for generics should not 
>> implicitly pull in a change to non-generic code. That seems fair. It 
>> may be the right thing to do, but it should be justified separately. 
>> So we're going to start with "any" only being accepted as a type 
>> constraint, and we can discuss making the name available for all uses 
>> separately, probably on issue 33232. Clearly adding "any" as a name 
>> accepted in type constraints is a step toward defining "any" for all 
>> code, but doing so isn't a requirement for generics. 
>>
>> Ian 
>>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/41f63ef1-ac34-4d43-88fc-4ce75bcc262dn%40googlegroups.com.