Re: [go-nuts] linker panics on ld.decodetypeKind

On Mon, Apr 8, 2019 at 8:52 PM wrote: > > I build .debs of Go which are used as a dependency for Prometheus debs. > Doing code upgrades I started getting a weird panic from the Go linker that I > don't see elsewhere on the Internet, and seems different from the cgo bug > that caused 1.12.3 to

[go-nuts] linker panics on ld.decodetypeKind

Friends, I build .debs of Go which are used as a dependency for Prometheus debs. Doing code upgrades I started getting a weird panic from the Go linker that I don't see elsewhere on the Internet, and seems different from the cgo bug that caused 1.12.3 to be released today. Below are the relev

[go-nuts] Proposal: test in one package can import functions from another package's test

I don't know you, but to me, writing Golang test is a little dreary. As a discussion, I think this proposal could bring some improvement. How do you like it? https://github.com/golang/go/issues/31135 -- You received this message because you are subscribed to the Google Groups "golang-nuts" gr

[go-nuts] Re: Go 1.12.3 and Go 1.11.8 are released

Corrected link to issue describing failures: https://golang.org/issue/31293 On Mon, Apr 8, 2019 at 6:28 PM Andrew Bonventre wrote: > Hello gophers, > > We have just released Go versions 1.12.3 and 1.11.8, minor point releases. > > These releases fix an issue where using the prebuilt binary relea

[go-nuts] Go 1.12.3 and Go 1.11.8 are released

Hello gophers, We have just released Go versions 1.12.3 and 1.11.8, minor point releases. These releases fix an issue where using the prebuilt binary releases on older versions of GNU/Linux led to failures when linking programs that used cgo. Only Linux users who

Re: [go-nuts] Why will it deadlock if a goroutine acquire a mutex while pinned to its P?

-Original Message- >From: Ian Lance Taylor >Sent: Apr 8, 2019 2:24 PM >To: Cholerae Hu , Austin Clements >Cc: golang-nuts >Subject: Re: [go-nuts] Why will it deadlock if a goroutine acquire a mutex >while pinned to its P? > >[ + austin ] > >On Sun, Apr 7, 2019 at 11:31 PM Cholera

Re: [go-nuts] why is this not ascending?

On Mon, Apr 8, 2019 at 10:15 AM T L wrote: > time.Sleep is not a synchronization method. > time.Sleep(dt) means pausing the execution of the current goroutine for at > least dt duration. > The actual paused duration may be longer than dt. > Not only is sleep not a synchronization method but I/O

Re: [go-nuts] Modifying the Runtime Scheduler

I have no experience with this code...but a lot of debugging experience. Since you think you know the general problem and have both hands inside the patient already, why not (for now) modify the GC scanner to always look at your batch’s pointer list and explicitly avoid messing with them. Then yo

Re: [go-nuts] Modifying the Runtime Scheduler

I am keeping an `allb` slice, and with that I did see it occasionally succeed. I am using the binarytree test, since it is an issue regarding the GC. In fact running it wit

Re: [go-nuts] Why will it deadlock if a goroutine acquire a mutex while pinned to its P?

[ + austin ] On Sun, Apr 7, 2019 at 11:31 PM Cholerae Hu wrote: > > I'm reading this commit > https://github.com/golang/go/commit/d5fd2dd6a17a816b7dfd99d4df70a85f1bf0de31 > . Inside runtime_procPin we only increases the m.lock count, why will it > cause deadlock when acquiring a mutex after p

Re: [go-nuts] Modifying the Runtime Scheduler

On Sun, Apr 7, 2019 at 12:30 PM Tharen Abela wrote: > > The gist of the problem is that I am allocating an object in the runtime, > (which I refer to as the batch struct), and the GC is deallocating the > object, even though a reference is being kept in a slice (similar to allp and > allm). > W

[go-nuts] Re: Modifying the Runtime Scheduler

I only posted the diffs for `proc.go`: Here are the diffs for `runtime2.go`: 0 <-> 1 , 1 <-> 2 On Sunday, 7 April 2019 17:43:06 UTC+2, Tharen Abela wrote: > > I'll preface this by

Re: [go-nuts] why is this not ascending?

If you add fmt.Println(runtime.NumCPU()), you'll see there's one CPU in the playground environment. When main calls sleep after printing 0, the go routine is ready to run, so it switches there, and prints 1. At that point, when the go routine sleeps, main is not runnable (it's still sleeping), so i

[go-nuts] Re: Modifying the Runtime Scheduler

I only posted the diffs for `proc.go`: Here are the diffs for `runtime2.go`: 0 <-> 1 , 1 <-> 2 On Sunday, 7 April 2019 17:43:06 UTC+2, Tharen Abela wrote: > > I'll preface this by saying this is for academic purposes.

Re: [go-nuts] why is this not ascending?

time.Sleep is not a synchronization method. time.Sleep(dt) means pausing the execution of the current goroutine for at least dt duration. The actual paused duration may be longer than dt. On Monday, April 8, 2019 at 9:38:40 AM UTC-4, go je wrote: > > ascending only work if i cut the first sleep h

Re: [go-nuts] Re: Can't figure out modules when depending on multi module repo

Since this is a mailing list, editing the post wouldn't help you much anyway. As soon as you make the original post it gets sent to everyone's email as-is. Best just to do exactly what you did and follow up with more info. On Mon, Apr 8, 2019 at 7:29 AM Vladislav Mitov wrote: > Since when I can'

Re: [go-nuts] why is this not ascending?

I added this at the top of your main "fmt.Println("CPU Count", runtime.NumCPU())", and found out that the playground uses 1 CPU, so your goroutines will not run concurrently. The scheduler will do a context switch whenever you call a any number of runtime functions, but it is fundamentally coopera

Re: [go-nuts] why is this not ascending?

To a first order approximation, there is no guarantee of events between any two go processes. The scheduler is free to chose any unblocked process. Here's what I think is happening. go sync () // creates the sync routine fmt.Println("0") // prints time.Sleep(time.Second) // sends this routine to

[go-nuts] Re: Can't figure out modules when depending on multi module repo

Since when I can't edit posts? Strange. The debug info was from before I pushed the first service to gitlab. Here is the correct one: WORK=/tmp/go-build828045533 > Fetching > https://gitlab.company.com/vladislav.mitov/service/pkg/client?go-get=1 > Parsing meta tags from > https://gitlab.comp

[go-nuts] Can't figure out modules when depending on multi module repo

Hello gophers, I'm migrating my codebase to modules and I encountered an issue that I can't figure how to solve. So, it is a code for a multi service application and each service is structured in the following way: . ├── service │ ├── cmd │ │ └── service │ │ ├── go.mod │ │

Re: [go-nuts] why is this not ascending?

ascending only work if i cut the first sleep half second to print them alternately but isn't they sequentially running? On Mon, Apr 8, 2019 at 9:30 PM go je wrote: > https://play.golang.org/p/0TIxVFuqGoB > > -- > You received this message because you are subscribed to the Google Groups > "golang

[go-nuts] why is this not ascending?

https://play.golang.org/p/0TIxVFuqGoB -- 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://gr

Re: [go-nuts] Re: [ANN] Gomail v2: sending emails faster

https://play.golang.org/p/lNbxCAxsqwd here is code On Monday, April 8, 2019 at 3:43:04 AM UTC+3, Michael Jones wrote: > > If those black boxes represent Go language code, please share it here by > pasting it into the Go Language Playground and then sharing a link in email > here. > > It is