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 &
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
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
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
> 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:
>
>
>
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
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
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.
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 (
> >
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
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
>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
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
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
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
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
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
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
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)
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
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
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
> 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
23 matches
Mail list logo
