Re: [go-nuts] when to use Sync pool

[Ian Lance Taylor]

On Fri, Oct 6, 2017 at 1:23 PM, XXX ZZZ  wrote:
>
> So we are making a platform where we have to use a TON of short lived
> structs, in order to optimize this we intend to use sync pool, however on
> our benchmark tests I have found that it only seems to improve performance
> when the struct is big enough, for smaller structs ie: (4-5 string values)
> it seems to be considerably slower, yet I see many packages (such as
> fasthttp) using sync pool for basically everything. Is there anything I am
> missing? Any recommendations of when to use sync pool?

Be careful in your benchmarks.  Make sure that the values are really
being allocated, and not simply being stored on the stack by the
compiler.  Check how often the GC is running; allocation that does not
trigger a GC is always going to be faster.

Use sync.Pool when you have code that uses an unpredictable number of
objects, where the allocation cost of the objects is noticeable
compared to the cost of the rest of the code (either because the
objects are large or because the rest of the code is fast), where you
want to scale the allocation require based on the use of the package.
Don't use sync.Pool if the number of objects is predictable: use a
free list.  Don't use it for basically everything; it won't actually
save you any time.  Use it for areas where the memory needs change
unpredictably during the course of the program.

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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] when to use Sync pool

[XXX ZZZ]

Hello,

So we are making a platform where we have to use a TON of short lived 
structs, in order to optimize this we intend to use sync pool, however on 
our benchmark tests I have found that it only seems to improve performance 
when the struct is big enough, for smaller structs ie: (4-5 string values) 
it seems to be considerably slower, yet I see many packages (such as 
fasthttp) using sync pool for basically everything. Is there anything I am 
missing? Any recommendations of when to use sync pool?

Thanks!

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] [security] Go 1.8.4 and Go 1.9.1 are released

[Bakul Shah]

On Fri, 06 Oct 2017 11:21:10 -0700 Rich  wrote:
Rich writes:
> curl https://storage.googleapis.com/golang/go1.9.1.darwin-amd64.tar.gz |
tar zxvf -
> That will overwrite the existing /usr/local/go directory.  To check:

You are not alone in making this mistake.  I made the *same*
mistake when installing a new release on a 32bit freebsd
machine and broke go (and wasted Ian's time by filing a bug
report).  You have to /replace/ the installation, not
/overwrite/ it. I forgot since I rarely build go program on
this machine.

There is a reason why on MacOS, Windows, Linux, *BSD etc. use
installers instead of just "tar x" or "unzip" as it allows the
installer to run a script to do the right thing (such as
checking there is enough space, doing some simple test to
check everything went ok, restore the old release if it didn't
etc). In spirit "go update" to "go get" what "pkg update" is
to "pkg install" or "brew update" is to "brew install".

> On Wednesday, October 4, 2017 at 9:41:00 PM UTC-4, Bakul Shah wrote:
> >
> > Would it make sense for Go to update itself? Something 
> > like "go update " that fetches a platform 
> > specific release, does some basic sanity tests and 
> > if all goes well, overwrites $GOROOT. 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] [security] Go 1.8.4 and Go 1.9.1 are released

[Rich]

On linux / mac I just become root, cd to /usr/local then run this one liner:

Mac:
  curl https://storage.googleapis.com/golang/go1.9.1.darwin-amd64.tar.gz | 
tar zxvf -

Linux64:
  curl https://storage.googleapis.com/golang/go1.9.1.linux-amd64.tar.gz | 
tar zxvf -

That will overwrite the existing /usr/local/go directory.  To check:

~] $ go version
go version go1.9.1 darwin/amd64

On Wednesday, October 4, 2017 at 9:41:00 PM UTC-4, Bakul Shah wrote:
>
> Would it make sense for Go to update itself? Something 
> like "go update " that fetches a platform 
> specific release, does some basic sanity tests and 
> if all goes well, overwrites $GOROOT. 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Hello, I have a question about the bottom of the goroutine

[Ian Lance Taylor]

On Fri, Oct 6, 2017 at 9:22 AM, 王晚成  wrote:
> hello ，
>  I have a question about the bottom of the goroutine.
> What is the meaning of the mstartfn field inside the M structure
> under runtime2.go?
> Is this mstartfn the function that we write behind the go statement?
> Or what other functions?
> Thanks very much!

mstartfn is used to start a few special purpose functions on a new M.
Specifically, in current master, the possible values are sysmon (the
system monitor thread), mhelpgc (a new thread ready to help the GC in
the future), and mspinning (starts the new thread in spinning state to
maintain some bookkeeping).

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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Hello, I have a question about the bottom of the goroutine

[王晚成]

hello ，
 I have a question about the bottom of the goroutine.
What is the meaning of the mstartfn field inside the M structure
under runtime2.go?
Is this mstartfn the function that we write behind the go statement?
Or what other functions?
Thanks very much!

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: [golang-dev] [security] Go 1.8.4 and Go 1.9.1 are released

[mcrowther]

Apologies, I missed that somehow. Thanks for the followup.

Molly Crowther
Cloud Foundry + Pivotal Security Team

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Are all running goroutines killed when main ends?

[Michael Jones]

This line of reasoning suggests an idea to me.

Defer has the grammatical notion of "i want to do this later, but
eventually, i don't want to forget to do it before i leave."

Imagine the slightly stronger notion of a "will" as in a person's last will
and testament. Actions in your will are steps to be carried out in the
event of your death. Presumably if an action has already been done during
your lifetime, then that part of the will is mooted.

Imagine a "will" statement in Go. Instead of Defer's chaining calls on the
local function's return, the Will would do that with a wrapper that would
set a bit saying "this has been done" but would also install a wrapper to
the call on a global list owned by the runtime, which would inspect the
bits at main's exit and call any functions that have not already been
called.

The function called at main's exit would be the 'executor' of the various
wills.

On Fri, Oct 6, 2017 at 1:08 AM, Mikhail Mazurskiy <
mikhail.mazur...@gmail.com> wrote:

> I wrote a library to help with this https://github.com/ash2k/stager
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Michael T. Jones
michael.jo...@gmail.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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Showing skipped tests in 'go test'

[matt . fozard]

Dear gophers,

I use feature detection and t.Skip for some of my tests, e.g. if 
!featureXPresent { t.Skip("feature X is not present" }
which works well, but when running the tests I would like 'go test' to 
remind me that some tests were skipped.

The only way I've found of listing the skipped tests is to run: go test -v 
./... | grep 'SKIP'
but this is clunky and hides the rest of the test output.

Is there a better way of doing this?

What I would *really* like though is a short summary of what was tested as 
part of the output from 'go test'.  For example:

ok  github.com/quru/foo/pkg/a0.004s[3 passed]
?   github.com/quru/foo/pkg/b[no test files]
ok  github.com/quru/foo/pkg/c0.010s[10 passed, 2 skipped]

Regards,
Matt

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: [golang-dev] [security] Go 1.8.4 and Go 1.9.1 are released

[Jakub Cajka]

Just for the record, I have requested CVEs to be assigned to these issues 
yesterday. They got CVE-2017-15041 and CVE-2017-15042, respectively. It is 
already noted in the issues by rsc.

JC

- Original Message -
> From: "Chris Broadfoot" 
> To: "golang-nuts" 
> Sent: Wednesday, October 4, 2017 10:33:32 PM
> Subject: [golang-dev] [security] Go 1.8.4 and Go 1.9.1 are released
> 
> Hi gophers,
> 
> Two security-related issues were recently reported.
> To address this issue, we have just released Go 1.8.4 and Go 1.9.1.
> 
> We recommend that all users update to one of these releases (if you're not
> sure which, choose Go 1.9.1).
> 
> The issues addressed by these releases are:
> 
> By nesting a git checkout inside another version control repository, it was
> possible for an attacker to trick the “go get” command into executing
> arbitrary code. The go command now refuses to use version control checkouts
> found inside other version control systems, with an exception for git
> submodules (git inside git).
> The issue is tracked as https://golang.org/issue/22125 (Go 1.8.4) and
> https://golang.org/issue/22131 (Go 1.9.1). Fixes are linked from the issues.
> Thanks to Simon Rawet for the report.
> 
> In the smtp package, PlainAuth is documented as sending credentials only
> over authenticated, encrypted TLS connections, but it was changed in Go 1.1
> to also send credentials on non-TLS connections when the remote server
> advertises that PLAIN authentication is supported. The change was meant to
> allow use of PLAIN authentication on localhost, but it has the effect of
> allowing a man-in-the-middle attacker to harvest credentials. PlainAuth now
> requires either TLS or a localhost connection before sending credentials,
> regardless of what the remote server claims.
> This issue is tracked as https://golang.org/issue/22134 (Go 1.8.4) and
> https://golang.org/issue/22133 (Go 1.9.1). Fixes are linked from the issues.
> Thanks to Stevie Johnstone for the report.
> 
> Downloads are available at https://golang.org/dl for all supported
> platforms.
> 
> Cheers,
> Chris (on behalf of the Go team)
> 
> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Are all running goroutines killed when main ends?

[Mikhail Mazurskiy]

I wrote a library to help with this https://github.com/ash2k/stager

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Are all running goroutines killed when main ends?

[go-question]

Thanks for clearing that up!


On Thursday, October 5, 2017 at 9:52:30 PM UTC-7, Dave Cheney wrote:
>
> The only answer I have is to ask those goroutines to exit, the wait for 
> them to exit. Context is part of this, combined with a waitgroup to track 
> goroutines in flight. 

-- 
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.
For more options, visit https://groups.google.com/d/optout.