Many thanks Ian!
On Friday, June 19, 2020 at 11:32:19 PM UTC+3, Ian Lance Taylor wrote:
>
> On Fri, Jun 19, 2020 at 12:29 PM Iskander Sharipov > wrote:
> >
> > I used this to write something like a runtime in Go.
> >
> > https://play.golang.org/p/6jYw5L3fy0B
> >
> > I was wondering whether
On Fri, Jun 19, 2020 at 12:29 PM Iskander Sharipov wrote:
>
> I used this to write something like a runtime in Go.
>
> https://play.golang.org/p/6jYw5L3fy0B
>
> I was wondering whether this code can break at some point.
I don't see any way that that code could break, but I agree that it
does not
I used this to write something like a runtime in Go.
https://play.golang.org/p/6jYw5L3fy0B
I was wondering whether this code can break at some point.
On Friday, June 19, 2020 at 10:04:01 PM UTC+3, Iskander Sharipov wrote:
>
> Hello!
>
> https://golang.org/src/runtime/symtab.go?s=7594:7745#L244
s/same/safe/
The question is about whether it's safe to do the same conversion outside
of the Go runtime.
On Friday, June 19, 2020 at 10:04:01 PM UTC+3, Iskander Sharipov wrote:
>
> Hello!
>
> https://golang.org/src/runtime/symtab.go?s=7594:7745#L244
>
> type Func struct {
>
> opaque
Ok, to give some update apparently our Makefile uses `build -i` where it
tries to install package dependency.
This explains the conflicted `.a` files.
It was there before GOCACHE to speed up `go build`
Thanks for the help!
On Wednesday, October 10, 2018 at 9:40:28 PM UTC+2, Yulrizka wrote:
>
It seems that after searching in google, I found couple of similar issue:
most of them are related to parallel build with "GNU parallel" which is in
our case as well.
https://github.com/gravitational/teleport/issues/1708
https://github.com/grpc/grpc-go/issues/368
I saw that you wrote
> The reason that I'm using shared GOPATH for this Jenkins step/job is that
to now download the packages in `pkg/mod`.
And I thought that meant you were using modules.
Discussion in https://github.com/golang/go/issues/26677 says that the build
cache is explicitly safe, but
Hi Mark,
what I find interesting is that I haven't enable go module yet.
As you can see in the errors that I'm still using a vendor directory
On Monday, October 1, 2018 at 6:27:57 PM UTC+2, Mark Rushakoff wrote:
>
> https://github.com/golang/go/issues/26794 is "can't run go builds
>
https://github.com/golang/go/issues/26794 is "can't run go builds
concurrently if they download modules".
In that issue, Russ says:
> There is a plan to make downloading of modules by parallel go commands safe
but we haven't done that yet.
On Monday, October 1, 2018 at 8:43:00 AM UTC-7,
Why not something simple like: https://play.golang.org/p/iAlflMUdEA
On Monday, November 20, 2017 at 9:48:31 AM UTC-7, Trig wrote:
>
> for i, user := range myList {
> if user.Disabled {
> myList = append(myList[:i], myList[i + 1:]...) // remove user from
> return list
> }
> }
>
>
> Is
You need to swap elements if you want to remove them from list while
iterating it. There are two ways to do this:
First: iterate backward. This will however, will change the order of
unremoved elements.
Second: iterate forward, and will preserve the order of the unremoved
elements.
I tend to be quite careful around removing items from an array/slice/list
and not just in Go.
Deletion of items is probably the most mutable thing you can do to a list -
if the list is shared between goroutines, it could really mess things up.
Rather than delete, I'd suggest a mark and copy
Don't use that way. You can try that another
approach: https://play.golang.org/p/Nu8zD1stOd
Em segunda-feira, 20 de novembro de 2017 14:48:31 UTC-2, Trig escreveu:
>
> for i, user := range myList {
> if user.Disabled {
> myList = append(myList[:i], myList[i + 1:]...) // remove user from
>
It is safe to call wg.Add fron multiple goroutines. The only caveat is that
wg.Wait must be synchronized with the first wg.Add (which it is in your
case because you call wg.Add(1) in the same goroutine as wg.Wait()).
The go source code is very readable, and easily accessible from godoc.
While it isn't necessary to alter GOMAXPROCS to detect a race (or it is
possible to have a data race at GOMAXPROCS==1) increasing the number of
goroutines that can run in parallel, sometimes to ludicrous levels can expose
non determinism in your code.
This is the script I use to test my
Thank you
I reread the document and still not quite sure if the function is safe to
be called concurrently.
So I try the race detector which is not outputting any report. (Mean safe I
supposed.)
Finally, I look at the source code which I found sync/atomic usage for
counter manipulation so I
You can safely call Add concurrently from multiple goroutines in some
cases. In the case of your example, I think it correctly satisfies the
conditions mentioned in the documentation:
> Note that calls with a positive delta that occur when the counter is zero
> must happen before a Wait.
https://play.golang.org/p/LadBqwgxxr _may_ be a fix, but the similarity to
the discredited double check lock pattern is worrying.
On Wednesday, 14 December 2016 15:32:57 UTC+11, Dave Cheney wrote:
>
> Nope, it's not safe.
>
> https://play.golang.org/p/pcPdKixphL
>
> Run this program in a loop
Nope, it's not safe.
https://play.golang.org/p/pcPdKixphL
Run this program in a loop and it will panic eventually.
On Wednesday, 14 December 2016 15:19:24 UTC+11, P Q wrote:
>
> func close_safe(c chan bool) {
> select {
> case <-c:
> default:
> close(c)
> }
> }
>
> Closing a channel onece more
On Oct 18, 2016 12:42 PM, "adonovan via golang-nuts" <
golang-nuts@googlegroups.com> wrote:
>
> On Tuesday, 18 October 2016 15:30:36 UTC-4, Joshua Liebow-Feeser wrote:
>>
>> are there any bits in a pointer which, when modified, won't mess with
the GC?
>
>
> Even if there are, using them would
On Tuesday, 18 October 2016 15:30:36 UTC-4, Joshua Liebow-Feeser wrote:
>
> are there any bits in a pointer which, when modified, won't mess with the
> GC?
>
Even if there are, using them would constrain the future choices of the GC
team, for which they will not thank you.
This seems like a
21 matches
Mail list logo
