by net.Conn
>
> bufr := bufio.newReader(netConn)
> for numEntries >0 {
> numEntries--
> netConn.setReadDeadline(timeNow().add(heartbeatTimeout)
> entry.decode(bufr)
> process(entry)
> }
>
> thanks
> Santhosh
>
> On Sat, Apr 6, 2019 at 4:09 PM Dav
Please don’t take os.File as justification, it’s one of the few uses of a
finaliser in the std lib. If it were being written today I would argue that
instead of silently closing the file, it should panic if the resource falls out
of scope unclosed.
As always, remember that finalisers are not
With the modules support added to Go 1.11 this should be straight forward.
Create a subdirectory for your go code inside your working copy; change
into that and run
go mod init example.com/your/repo
Where example.com/your/repo is a placeholder for the _prefix_ you want to
apply to all of the
My suggestion is, rather than seeing if an executable exists, then executing
it. Just execute it and if there is an error just pass it back to the caller.
The difference between I tried to run the program but it wasn’t found and I
tried to run the program but it failed for some reason shouldn’t
Are you able to modify the original question. Why do you need to know if a
binary exists? Presumably so you can execute it. If so then you can modify the
original request and make the problem more tractable.
--
You received this message because you are subscribed to the Google Groups
On Tuesday, 25 September 2018 10:22:52 UTC+10, Louki Sumirniy wrote:
>
> Using named return values and this construction you can drop all those
> returns in each case block to outside the block. You only need to spend an
> extra line if you have to break out of it by return or break.
>
Go is
Additions to the language are handled via a written proposal process.
https://github.com/golang/proposal/blob/master/README.md
--
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,
Sorry, I probably wasn’t clear or didn’t understand that you were asking. I saw
that you said GOPATH is not set, it because your code is inside $HOME/go,
because of the rules of the default gopath introduced in 1.8, gopath IS
actually set.
To be extra sure, when I’m playing with go modules I
I think because GOPATH is not set it is defaulting to $HOME/go (see Go 1.9
release notes, from memory). Try moving your code to another folder.
On Friday, 21 September 2018 05:21:32 UTC+10, John wrote:
>
> Just started playing with modules recently. Having an issue I don't
> understand,
If you pass more -m's to the compiler it will explain why
Daves-MacBook-Pro(~/src) % go build -gcflags=-m=2 buffer.go
# command-line-arguments
./buffer.go:12:6: cannot inline main: function too complex: cost 108
exceeds budget 80
./buffer.go:15:21: buffer escapes to heap
./buffer.go:15:21:
Thank you to everyone who has contributed to this thread.
It is time for everyone to take a break for 48 hours. After this time if you
feel strongly that there is a point which you must continue to debate please do
so, but be mindful that many words have already been spent in this thread and
the stdlib which gave me what i wanted.
>> On Tue, Sep 18, 2018 at 7:55 PM Dave Cheney wrote:
>>
>> pkg /profile will do the paperwork for you so ^C works when profiling.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>&g
pkg /profile will do the paperwork for you so ^C works when profiling.
--
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.
It looks like the playground has cached this error. Please raise an issue,
https://golang.org/issue/new and someone with admin powers will delete the
faulty entry.
On Tuesday, 18 September 2018 17:03:00 UTC+10, Reinhard Luediger wrote:
>
> Hey List,
>
> is this the right place to get the tour
Assuming you are using the master branch of go-ifps-api, this request is
failing because RequestBuilder.shell is nil. This could happen for a
variety of reasons, perhaps the lack of error handling in NewLocalShell.
I recommend you handle this with the ipfs developers on
I've confirmed this uses 14% on a random OS X machine. Please raise a bug,
https://golang.org/issue/new
On Monday, 17 September 2018 14:29:44 UTC+10, Robert Engels wrote:
>
> For reference, similar code under Java consumes 2.5 % CPU.
>
> I tested the Go code under OSX, and it is roughly 10%,
I think D solved this quite well
https://dlang.org/spec/template.html
In your example this might become
type Foo(type T) interface {}
type Bar(type T) interface {
Foo!(T)
}
The exclamation point makes it clear this is the application of a T to the
existing interface type Foo(type T).
On
Go 1.11 doesn't support XP. We don't test on XP and won't fix bugs reported
against XP systems any more. If it's working for you, great!, but if it
breaks, you get to keep both pieces.
Dave
On Tuesday, 11 September 2018 05:05:23 UTC+10, wilk wrote:
>
> Hi,
>
> Go 1.11 is not more compatible
I'm sorry you feel this way.
The reality is that the format of the language is not something that is
going to change. I personally don't like that I cannot write one liner
functions on one line because of gofmt's preference for reformatting the
same function over three lines -- but, I put this
This looks like an issue related to dns resolution in your environment with go
1.11.
I suggest building a reproducer using the net,Lookup* functions as the net/http
package is not the problem. Once you have a reproduction case, please log an
issue golang.org/issue/new
Thanks.
--
You
Can you post the output from httpstat?
--
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
Hi John
Unless the variables a1, a2, a3, b1, ... are defined in the same package as
your showBoard function, ie
var a1, a2, a3 int
then Go will report that they are undefined. Unlike some other languages,
Go does not implicitly define a variable on first occurance. All variables
must be
Hi,
Can you please do two things to help with this error report.
1. Please include the entire data race report -- we need this to match up
the line with the source code you've provided in the gist
2. Please double check that you are not copying a your sync.Pool type by
value, this can happen
Thanks for confirming this is a regression.
On 20 August 2018 at 18:41, Shulhan wrote:
> On Sun, 19 Aug 2018 16:13:00 -0700 (PDT)
> Dave Cheney wrote:
>
>> Point of clarification, the package name doesn’t contain a dot, that
>> is not permitted by the syntax of the package
Point of clarification, the package name doesn’t contain a dot, that is not
permitted by the syntax of the package declaration. The name of the directory
you placed the file in ends in .go and this is confusing the tool.
If this is a regression from an earlier version of Go, please raise an
n, what happens to the error, is it dropped?
On Thursday, 16 August 2018 14:44:08 UTC+10, Dave Cheney wrote:
>
> What would happen if you write the error to spanner with a setting
> context.Backgrond(), ie, no deadline?
>
> On 16 August 2018 at 13:57, Robert Bartoszynski wro
d pass that to OtherService, with
> the expectation that there should be x seconds left over for the write to
> spanner.
>
> On Wed, Aug 15, 2018 at 8:10 PM Dave Cheney wrote:
>>
>>
>>
>> On Thursday, 16 August 2018 12:15:57 UTC+10, r...@google.com wrote:
>>
On Thursday, 16 August 2018 12:15:57 UTC+10, r...@google.com wrote:
>
> As an example:
> Client calls MyService with a deadline of 10 seconds.
> MyService calls OtherService as part of responding. However, the call to
> OtherService times out due to the deadline in 10 seconds.
> MyService tries
I don’t think that will help. The problem is not cross compilation. The problem
is when run in a 32bit environment the offset of that field is not guaranteed
to be aligned to 8 bytes. You’ve got a 50/50 chance that each allocation will
be properly aligned.
--
You received this message
No, it’s not a cross compilation issue. Well, yes and no, the rpi is a 32 bit
platform so some structures have a different size causing the offset of the
field to be 32 but aligned, not the required 64 bit aligned.
The play example shows the address of the field is not aligned on a 8 byte
This is likely to be
issue https://github.com/golang/go/issues/599,
https://play.golang.org/p/zZm-6zWwFoi
On Monday, 13 August 2018 01:29:43 UTC+10, Stephan Mühlstrasser wrote:
>
> Hi,
>
> I'm developing my first Go program that is supposed to upload files into a
> Google Cloud Storage bucket
The context value you pass into record isn't used and running record in its
own goroutine doesn't really add anything because the main goroutine just
waits for the other goroutine to exit. The exit the second goroutine will
be at least 1 second, but could be much longer.
On Saturday, 11 August
As Ian explained on the GitHub issue you raised, RHEL5 is not supported by any
version of Go - the 2.6.18 kernel is below our minimum requirements.
Dave
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop
So that it can be used interchangeably with *bufio.Writer.
--
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
Pass a pointer, *Set into your Diff method.
--
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
The execution tracer will show this as it tracks resources that goroutines
block on.
Seriously I’m just going to keep suggesting the execution tracer until you try
it :)
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from
The best tool to investigate this problem is the execution tracer. It will show
you the activity of goroutines over time making is easy to spot contention.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop
Please keep in mind that the Via header is supplied by he client (the browser)
and there is not requirement that it maintains the full chain of custardy of
all the urls it has passed though, nor is there any way for Go to know nor
enforce that this list remains accurate. Sorry.
--
You
Thank you to all those who contributed to this thread. While many Go
programs are written under open source licences, and many Go programmers
contribute to open source in a professional or personal capability, it is
now time to bring the discussion to a close as this thread has moved
outside
Top tip: you never need to set GOROOT. Please don’t set GOROOT, it’ll just
cause confusing errors for you in the future.
--
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
This is issue https://github.com/golang/go/issues/22579
On Tuesday, 1 May 2018 20:38:26 UTC+2, xiof...@gmail.com wrote:
>
> I just discovered a problem running/compiling files that are
> accessed/backed up by windows OneDrive
>
> (don't know when this started - worked a couple of months ago..)
>
The leak is here
httpClient := {Timeout: timeout, Transport: {Dial
: dialer.Dial}}
If the httpClient value goes out of scope the connections attached to that
will leak, along with their associated goroutines.
On Monday, 30 April 2018 07:56:43 UTC+2, Tamás Gulácsi wrote:
>
> Where do you Close
Try upgrading to go 1.10. You’ll get build and test caching for free and you’ll
see a small variance between the timings you reported.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails
If the path start with _ then it is not within the list of directories in your
GOPATH.
--
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
It depends on how you installed ypthe previous version of go. Home brew is
popular on the Mac so follow their instructions for upgrading a package
installed via brew.
If you used one of the options from the golang org website, simply remove
/usr/local/go and follow the instruction on the
Looking at the code for Discover it is possible you are discarding several
errors whose contents may explain the issue you see on windows.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails
Try putting a blank line between your comment block and the next symbol. This
will break the association between the comment block and the symbol and hide
the former.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this
Please have a read of my talk on solid from 2016.
https://dave.cheney.net/2016/08/20/solid-go-design
Tldr: define an interface with the behaviour of the os.File that your
function/method expects.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts"
Indeed. Please do not conflate popularity with ubiquity. Formula one is a very
popular sport, but not everyone needs to do 180mph down the straight away for
their daily commute.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe
for their product.
On Wednesday, 4 April 2018 21:52:08 UTC+10, sothy shan wrote:
>
>
>
> On Tuesday, April 3, 2018 at 4:50:36 PM UTC+2, Dave Cheney wrote:
>>
>> I’ve not seen that problem before. I’d hazard a guess that it’s an
>> incorrect go installation. Don’t set goroot,
> But is it not guaranteed that runtime.Gosched() will at least check if
another goroutine is runnable?
It checks, but I believe that at the time that it checks there are often no
other runnable goroutines. The execution tracer will give you the answer to
this.
On Wednesday, 4 April 2018
I’ve not seen that problem before. I’d hazard a guess that it’s an incorrect go
installation. Don’t set goroot, basically ever. But it’s just a guess.
Are you able to create a stand alone program that demonstrates the issue with
the profile? Please consider raising a bug, golang.org/issue/new
A printf, especially the first one in the program is likely to cause the
goroutine going off to the write(2) syscall to block long enough that a new
thread is created to replace it. Once the original thread comes back from
the syscall it will find that it has nothing to do, as you set runtime
It looks like you’re stopping the block profile immediately after starting it.
Try github.com/pkg/profile which will take care of the plumbing for you.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop
This windows build dependencies are captured
here, https://github.com/golang/go/wiki/WindowsBuild
On Thursday, 29 March 2018 00:17:32 UTC+11, Luke Mauldin wrote:
>
> Can someone please tell me what the golang team uses as the reference
> windows x64 compiler? I have heard references to mingw64
On Wednesday, 7 March 2018 07:39:56 UTC+11, andrey mirtchovski wrote:
>
> maybe this will give you a hint: https://play.golang.org/p/ANIjc3tCdwp
>
> maps are reference types, but they still get passed by value.
>
Maps are pointers, pointers are values.
--
You received this message because
Under the hood go get shells out to git to fetch source code. You need to
install git.
--
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
I prefer the later when possible because it enables callers to use the zero
value of a type without explicit initialisation.
On Sunday, 4 March 2018 11:37:43 UTC+11, Anmol Sethi wrote:
>
> How do you guys choose between constructors and lazy initialization?
>
> For example.
>
> Struct
Ahh, thank you. That was the missing piece of my understanding.
--
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
I don't understand how that could happen. time.Now calls time.now (which is
in assembly) so the former shouldn't be inlined, or omitted from profiling.
On Monday, 26 February 2018 14:02:13 UTC+11, Caleb Spare wrote:
>
> On a hunch, I profiled a benchmark which just calls time.Now in a loop.
>
Type C conforms to the T1 interface?
What did you expect?
--
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
The failing line was added in december last year,
https://github.com/golang/go/commit/7cba779cea5#diff-56c7df71bce32f8e50115128ae30941eR13
This also adds a dependency on time.h. Is time.h available in your build
container?
On Friday, 23 February 2018 20:09:02 UTC+11, Владислав Митов wrote:
>
>
Is there a reason DERO chose to go with their own licence rather than a
BSD, MIT, or Apache 2 licence?
On Monday, 19 February 2018 16:10:14 UTC+11, 867crypt...@gmail.com wrote:
>
> Hello, my name is Serena, I’m the Community Manager at a blockchain
> project called Dero. We use a protocol
I recommend watching this presentation from Russ Cox about why the Go team
decided to rewrite the compiler from C to Go.
https://www.youtube.com/watch?v=QIE5nV5fDwA
On Monday, 19 February 2018 11:44:23 UTC+11, Compiler wrote:
>
> Performance of C with Optimize not better of Go at more time?!
>
ler
>
> On Monday, February 19, 2018 at 3:22:27 AM UTC+3:30, Dave Cheney wrote:
>>
>> Stop.
>>
>> What do you want to do?
>>
>> Do you want to write a C compiler ?
>>
>> On Monday, 19 February 2018 10:47:24 UTC+11, Compiler wrote:
>>>
>&
Stop.
What do you want to do?
Do you want to write a C compiler ?
On Monday, 19 February 2018 10:47:24 UTC+11, Compiler wrote:
>
> https://groups.google.com/forum/#!topic/golang-nuts/24pSm-B3FqU
>
> On Monday, February 19, 2018 at 3:14:48 AM UTC+3:30, Dave Cheney wrote:
tten in a mixture of Go, C, and Assembly.
>>
>>>
>>> On Monday, February 19, 2018 at 3:01:35 AM UTC+3:30, Compiler wrote:
>>>>
>>>> mean all `.c` file in /src/ compile using own c-compiler?!
>>>>
>>>> On Monday, February 19, 201
In theory, yes. In practice, I doubt it.
On Monday, 19 February 2018 10:37:14 UTC+11, Compiler wrote:
>
> Can build only c(own) compiler using a c compiler(like gcc) without go
> from this source?!
>
>
> On Monday, February 19, 2018 at 2:48:26 AM UTC+3:30, Dave Cheney wrote:
;>
>> On Monday, February 19, 2018 at 2:49:40 AM UTC+3:30, Dave Cheney wrote:
>>>
>>> > which files require go-c compiler?
>>>
>>> The ones in the go 1.4distributuon that end in .c.
>>>
>>
--
You received this message because you ar
n /src/ compile using own c-compiler?!
>
> On Monday, February 19, 2018 at 2:49:40 AM UTC+3:30, Dave Cheney wrote:
>>
>> > which files require go-c compiler?
>>
>> The ones in the go 1.4distributuon that end in .c.
>>
>
--
You received this message
> which files require go-c compiler?
The ones in the go 1.4distributuon that end in .c.
--
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
> what files require the c compiler?
The c files in the go 1.4 distribution.
--
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
I feel like we’ve had this same discussion a few months ago.
Ian has mentioned that go 1.4 is no longer in use (it exists only in a very
special case or bootstrapping from source).
Can you please give some context to your questions so we may assist you better.
--
You received this message
In Go 1.4 the project contained both .go files and .c files. It shipped
with two compilers, a go compiler, called gc, and a c compiler called cc.
> /go/src/cmd/gc/go.y
This is the input file for the yacc grammar for the Go 1.4 go compiler
> /go/src/cmd/cc/cc.y
This is the input file for the
I certainly don’t want what happened to C++ to happen to Go. If it’s a choice
between obsolescence or being crushed under the weight of self inflicted
complexity, I’ll gladly vote with my feet for the former.
--
You received this message because you are subscribed to the Google Groups
cgo is not go.
--
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
Your program has a data race in the exitcode variable.
--
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
Your argument that the stdlib grows a uuid package is really a call for
stability. “3rd parties cannot provide us the stability we need, so the go team
must”. I don’t think that is a fair expectation on the go team, especially as
there is no clear standard for what a uuid is (having multiple
But that’s the problem, who’s default uuid format is chosen? And how to justify
this over the other users who want their default to be chosen.
The answer is as it currently stands, multiple uuid libraries exist outside the
standard library.
Can you tell me, in concrete terms, what are the
Which version of Go are you using?
https://github.com/golang/go/blob/master/src/net/pipe.go#L224
--
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
The build system considers android and Linux to be the same for historical
reasons.
--
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
Hi,
Can you please provide the output from running,
go env
It looks like your GOPATH variables is either not set, or not set to the
correct value, which in this case looks to be,
/home/vuco/repos/gopkg
--
You received this message because you are subscribed to the Google Groups
Can you please provide the output from running to eng.
It looks like your GOPATH variables is either not set, or not set to the
correct value, which looks to be in this case
/home/vuco/repos/gopkg
--
You received this message because you are subscribed to the Google Groups
"golang-nuts"
I am running the same version and do not see that errro. Have you modified your
ulimit? Does your machine have any sort of antivirus or monitoring software
installed?
In any case, I would say you can ignore that error, Go is correctly built by
that time.
--
You received this message
A long time ago getg was written in assembly in the runtime package. These
days it is implemented directly as pseudo instruction in the compiler.
Search for OpGetG in $GOROOT/src/cmd/compile/internal
On Wednesday, 17 January 2018 12:40:48 UTC+11, Jiajun Huang wrote:
>
> Hi, all:
>
> I'm
> Could anybody let me know what is wrong with my go program and how to
make it run faster?
Stop using gorun. You're timing how long it takes to compile, link, and
then run your program.
On Wednesday, 17 January 2018 07:18:47 UTC+11, peng...@gmail.com wrote:
>
> Hi,
>
> I made the following Go
> The body of the two functions differs only by a single ":", and yet, the
> output of the Printf calls differs.
This is not correct. The significant difference is one version has a named
return value, the other does not. The named return value allows you to capture
(by name) the return value
The best way to get help for this is to show us precisely what you
did, ideally in a small complete, stand-alone, example, and tell us
what you expected to happen, and tell us precisely what happened
instead.
--
You received this message because you are subscribed to the Google Groups
> fmt.Printf("%#v %#v\n", tr.Td, , tr.Td[0])
This line will not compile, are you sure this is the code that is executing?
--
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,
On Friday, 5 January 2018 01:15:16 UTC+11, matthe...@gmail.com wrote:
>
> Tong, I’m glad this works for you.
>
> Dave, reading back I see that we’re giving conflicting advice on pointers
> for MyTokenizer. While my view is that the dereferences are not necessary
> here, perhaps you have other
Put your methods on *MyTokenizer.
On Wednesday, 3 January 2018 14:52:41 UTC+11, Tong Sun wrote:
>
> I gave it a try, but unfortunately, it doesn't work for me.
>
> To begin with, this works,
>
> type MyTokenizer struct {
> *html.Tokenizer
> }
>
> func NewMyTokenizer(i io.Reader)
On 29 Dec 2017, at 18:01, Caleb Spare wrote:
>>> This expression:
>>>
>>> atomic.StoreUint32(, 1)
>>>
>>> does not just take the address of o.done. It also executes the
>>> StoreUint32 function, which is defined by the sync/atomic
>>> documentation to behave like '*o.done
On Friday, 29 December 2017 16:55:37 UTC+11, Caleb Spare wrote:
>
> > My argument is all that 'happens-before' is a comparison of o.done ==
> > 0 happens before the address of o.done is passed to
> > atomic.StoreUint32. The rest is just luck.
>
> This expression:
>
> atomic.StoreUint32(, 1)
On Fri, Dec 29, 2017 at 3:52 PM, Caleb Spare wrote:
> My argument is made without reference to registers, liveness,
> inlining, or any of that.
>
> The memory model defines certain behavior of mutexes (intuitively,
> it's how you think they would work) and sync/atomic defines
rmixing of atomic and non atomic loads.
>
> On Thu, Dec 28, 2017 at 7:11 PM, Dave Cheney <d...@cheney.net> wrote:
>> I think you are right, all access to that field should go via atomic
>> load/store operations. I don’t think it’s safe to mix those operations wth
>>
I think you are right, all access to that field should go via atomic load/store
operations. I don’t think it’s safe to mix those operations wth normal loads
and stores even within the same goroutine.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts"
Yes, please see the description of the operation of th garbage collector.
https://github.com/golang/go/blob/master/src/runtime/mgc.go#L66
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails
I’m sorry I don’t understand the question you are asking but what I see from
those gc times is your go busy() goroutine is blocking the STW1 phase because
Go cannot currently preempt running functions.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts"
On Sunday, 24 December 2017 05:18:14 UTC+11, Tim Peoples wrote:
> I've noticed a somewhat common practice of people naming their github
> repositories with a "go-" prefix (and then, of course, subsequently dropping
> the prefix in the actual package name) -- yet a similar naming scheme doesn't
Not that I’m aware of.
--
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
1 - 100 of 647 matches
Mail list logo