Re: [go-nuts] TestSetuidEtc fails during test execution in a container

['Andrew G. Morgan' via golang-nuts]

As a quick hack, you could just delete the src/syscall/syscall_linux_test.go 
file. Obviously, that will not test a bunch of stuff, but it should unblock 
you.

Alternatively, you could try one of the 'Download' options from:

   https://go-review.googlesource.com/c/go/+/319591/

while we go through the review cycle for this change (or something evolved 
from it).

Cheers

Andrew

On Wednesday, May 12, 2021 at 8:27:35 PM UTC-7 ksri...@gmail.com wrote:

> Yes I was wondering about that.
>
> Meanwhile, is there a way to exclude that test ?
>
> Kumar
>
> On Wed, May 12, 2021, 7:31 PM 'Andrew G. Morgan' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> Mea culpa. I clearly misread the capsh output.
>>
>> There is a cap_setgid in there. Looking closer at the output the 
>> miscompare is there in the first line. The groups are listed in an unsorted 
>> order. That is not expected by the test. Let me see what is causing this to 
>> happen. I'll use the bug to investigate and document what I find.
>>
>> Cheers
>>
>> Andrew
>>
>> On Wednesday, May 12, 2021 at 3:48:15 PM UTC-7 Andrew G. Morgan wrote:
>>
>>> OK. I've filed this bug. If we want to go this route, please assign it 
>>> to me:
>>>
>>> https://github.com/golang/go/issues/46145
>>>
>>>
>>> On Wednesday, May 12, 2021 at 2:53:19 PM UTC-7 Ian Lance Taylor wrote:
>>>
 On Wed, May 12, 2021 at 2:47 PM 'Andrew G. Morgan' via golang-nuts 
  wrote: 
 > 
 > 
 > It looks like the CapBound here is non-default. That is, this 
 container is running with non-default restrictions. 
 > 
 > $ /sbin/capsh --decode=0xa80425fb 
 > 
 0xa80425fb=cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap
  

 > 
 > The environment appears to be denying cap_setgid - which is why the 
 Setgroups() call is failing. 
 > 
 > Is adjusting that environmental choice possible? 

 Alternatively, can the test code detect that those restrictions are 
 being applied, and skip the test in that case? That's our usual 
 pattern for tests that can't be run in some environments. Thanks. 

 Ian 


 > On Wednesday, May 12, 2021 at 2:34:09 PM UTC-7 Ian Lance Taylor 
 wrote: 
 >> 
 >> [ + agm ] 
 >> 
 >> On Wed, May 12, 2021 at 2:12 PM Kumar Srinivasan  
 wrote: 
 >> > 
 >> > Hello, 
 >> > 
 >> > This is the first time I am posting to this group, apologies if 
 this is the wrong forum. 
 >> > 
 >> > I am trying to build the go sources and test the built sources, so 
 effectively I am running 
 >> > % cd go-source-dir/src && GOROOT_BOOTSTRAP=/BOOT_GO bash 
 ./all.bash 
 >> > I am seeing this failure attached below when I build and test 
 within a container. 
 >> > However I don't see this issue in a Virtual Machine running 
 CentOS7. 
 >> > 
 >> > Appreciate any help or insights anyone can offer. 
 >> > 
 >> > Thanks 
 >> > Kumar Srinivasan 
 >> > 
 >> > % uname -a 
 >> > 
 >> > Linux 7bb298e4-71d7-4f5e-4d4c-d58ac8ce61ac 4.15.0-76-generic 
 #86-Ubuntu SMP Fri Jan 17 17:24:28 UTC 2020 x86_64 
 >> > 
 >> >  
 >> > --- FAIL: TestSetuidEtc (0.12s) 
 >> > syscall_linux_test.go:668: [6] "Setgroups([]int{0,1,2,3})" 
 comparison: "/proc/32911/status" got:"Groups:\t1 2 3 0" want:"Groups:\t0 1 
 2 3" (bad) [pid=32911 file:'Name: syscall.test 
 >> > Umask: 0022 
 >> > State: S (sleeping) 
 >> > Tgid: 32911 
 >> > Ngid: 0 
 >> > Pid: 32911 
 >> > PPid: 10324 
 >> > TracerPid: 0 
 >> > Uid: 0 0 0 0 
 >> > Gid: 0 0 0 0 
 >> > FDSize: 64 
 >> > Groups: 1 2 3 0 
 >> > NStgid: 32911 
 >> > NSpid: 32911 
 >> > NSpgid: 7 
 >> > NSsid: 7 
 >> > VmPeak: 1092152 kB 
 >> > VmSize: 1034812 kB 
 >> > VmLck: 0 kB 
 >> > VmPin: 0 kB 
 >> > VmHWM: 5372 kB 
 >> > VmRSS: 5372 kB 
 >> > RssAnon: 1416 kB 
 >> > RssFile: 3956 kB 
 >> > RssShmem: 0 kB 
 >> > VmData: 169344 kB 
 >> > VmStk: 132 kB 
 >> > VmExe: 1384 kB 
 >> > VmLib: 1464 kB 
 >> > VmPTE: 140 kB 
 >> > VmSwap: 0 kB 
 >> > HugetlbPages: 0 kB 
 >> > CoreDumping: 0 
 >> > Threads: 8 
 >> > SigQ: 2/128577 
 >> > SigPnd:  
 >> > ShdPnd:  
 >> > SigBlk:  
 >> > SigIgn: 0030 
 >> > SigCgt: fffdffc1feff 
 >> > CapInh: a80425fb 
 >> > CapPrm: a80425fb 
 >> > CapEff: a80425fb 
 >> > CapBnd: a80425fb 
 >> > CapAmb:  
 >> > NoNewPrivs: 0 
 >> > Seccomp: 2 
 >> > Speculation_Store_Bypass: thread force mitigated 
 >> > Cpus_allowed: ff 
 >> > Cpus_allowed_list: 0-7 
 >> > Mems_allowed: 
 

Re: [go-nuts] TestSetuidEtc fails during test execution in a container

[Kumar Srinivasan]

Yes I was wondering about that.

Meanwhile, is there a way to exclude that test ?

Kumar

On Wed, May 12, 2021, 7:31 PM 'Andrew G. Morgan' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Mea culpa. I clearly misread the capsh output.
>
> There is a cap_setgid in there. Looking closer at the output the
> miscompare is there in the first line. The groups are listed in an unsorted
> order. That is not expected by the test. Let me see what is causing this to
> happen. I'll use the bug to investigate and document what I find.
>
> Cheers
>
> Andrew
>
> On Wednesday, May 12, 2021 at 3:48:15 PM UTC-7 Andrew G. Morgan wrote:
>
>> OK. I've filed this bug. If we want to go this route, please assign it to
>> me:
>>
>> https://github.com/golang/go/issues/46145
>>
>>
>> On Wednesday, May 12, 2021 at 2:53:19 PM UTC-7 Ian Lance Taylor wrote:
>>
>>> On Wed, May 12, 2021 at 2:47 PM 'Andrew G. Morgan' via golang-nuts
>>>  wrote:
>>> >
>>> >
>>> > It looks like the CapBound here is non-default. That is, this
>>> container is running with non-default restrictions.
>>> >
>>> > $ /sbin/capsh --decode=0xa80425fb
>>> >
>>> 0xa80425fb=cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap
>>>
>>> >
>>> > The environment appears to be denying cap_setgid - which is why the
>>> Setgroups() call is failing.
>>> >
>>> > Is adjusting that environmental choice possible?
>>>
>>> Alternatively, can the test code detect that those restrictions are
>>> being applied, and skip the test in that case? That's our usual
>>> pattern for tests that can't be run in some environments. Thanks.
>>>
>>> Ian
>>>
>>>
>>> > On Wednesday, May 12, 2021 at 2:34:09 PM UTC-7 Ian Lance Taylor wrote:
>>> >>
>>> >> [ + agm ]
>>> >>
>>> >> On Wed, May 12, 2021 at 2:12 PM Kumar Srinivasan 
>>> wrote:
>>> >> >
>>> >> > Hello,
>>> >> >
>>> >> > This is the first time I am posting to this group, apologies if
>>> this is the wrong forum.
>>> >> >
>>> >> > I am trying to build the go sources and test the built sources, so
>>> effectively I am running
>>> >> > % cd go-source-dir/src && GOROOT_BOOTSTRAP=/BOOT_GO bash
>>> ./all.bash
>>> >> > I am seeing this failure attached below when I build and test
>>> within a container.
>>> >> > However I don't see this issue in a Virtual Machine running
>>> CentOS7.
>>> >> >
>>> >> > Appreciate any help or insights anyone can offer.
>>> >> >
>>> >> > Thanks
>>> >> > Kumar Srinivasan
>>> >> >
>>> >> > % uname -a
>>> >> >
>>> >> > Linux 7bb298e4-71d7-4f5e-4d4c-d58ac8ce61ac 4.15.0-76-generic
>>> #86-Ubuntu SMP Fri Jan 17 17:24:28 UTC 2020 x86_64
>>> >> >
>>> >> > 
>>> >> > --- FAIL: TestSetuidEtc (0.12s)
>>> >> > syscall_linux_test.go:668: [6] "Setgroups([]int{0,1,2,3})"
>>> comparison: "/proc/32911/status" got:"Groups:\t1 2 3 0" want:"Groups:\t0 1
>>> 2 3" (bad) [pid=32911 file:'Name: syscall.test
>>> >> > Umask: 0022
>>> >> > State: S (sleeping)
>>> >> > Tgid: 32911
>>> >> > Ngid: 0
>>> >> > Pid: 32911
>>> >> > PPid: 10324
>>> >> > TracerPid: 0
>>> >> > Uid: 0 0 0 0
>>> >> > Gid: 0 0 0 0
>>> >> > FDSize: 64
>>> >> > Groups: 1 2 3 0
>>> >> > NStgid: 32911
>>> >> > NSpid: 32911
>>> >> > NSpgid: 7
>>> >> > NSsid: 7
>>> >> > VmPeak: 1092152 kB
>>> >> > VmSize: 1034812 kB
>>> >> > VmLck: 0 kB
>>> >> > VmPin: 0 kB
>>> >> > VmHWM: 5372 kB
>>> >> > VmRSS: 5372 kB
>>> >> > RssAnon: 1416 kB
>>> >> > RssFile: 3956 kB
>>> >> > RssShmem: 0 kB
>>> >> > VmData: 169344 kB
>>> >> > VmStk: 132 kB
>>> >> > VmExe: 1384 kB
>>> >> > VmLib: 1464 kB
>>> >> > VmPTE: 140 kB
>>> >> > VmSwap: 0 kB
>>> >> > HugetlbPages: 0 kB
>>> >> > CoreDumping: 0
>>> >> > Threads: 8
>>> >> > SigQ: 2/128577
>>> >> > SigPnd: 
>>> >> > ShdPnd: 
>>> >> > SigBlk: 
>>> >> > SigIgn: 0030
>>> >> > SigCgt: fffdffc1feff
>>> >> > CapInh: a80425fb
>>> >> > CapPrm: a80425fb
>>> >> > CapEff: a80425fb
>>> >> > CapBnd: a80425fb
>>> >> > CapAmb: 
>>> >> > NoNewPrivs: 0
>>> >> > Seccomp: 2
>>> >> > Speculation_Store_Bypass: thread force mitigated
>>> >> > Cpus_allowed: ff
>>> >> > Cpus_allowed_list: 0-7
>>> >> > Mems_allowed:
>>> ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,0001
>>>
>>> >> > Mems_allowed_list: 0
>>> >> > voluntary_ctxt_switches: 22
>>> >> > nonvoluntary_ctxt_switches: 52
>>> >> > ' Pid: 32911]
>>> >> > FAIL
>>> >> > FAIL syscall 0.724s
>>> >> >
>>> >> > 
>>> >> >
>>> >> > --
>>> >> > 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 

Re: [go-nuts] Still "missing" priority or ordered select in go?

[robert engels]

Here is a simple priority select implementation using unbuffered channels. 
https://play.golang.org/p/Hvl0iMr-cFW 

Uncomment the lines as instructed and you will see that channel A is always 
picked.

What this demonstrates is that ‘priority’ and ‘event order’ is highly dependent 
on latency, event frequency, etc. The ’sleep’ + locks in this example function 
as an external clock - as long as all events are ready at the clock edge you 
can implement priority - but with async events and scheduling - priority is 
impossible.

(In the absence of the sleep - the Go scheduler + OS scheduler determines 
whether A or B will run and scheduling delays will allow B events to arrive 
before an A event.

You can also trivially change this example to implement the ‘close A, close B’ 
scenario using a single Go routine and will see the desired ’never ends’ state 
is obtained.

(btw - there are probably some deadlock scenarios - I didn’t spend a lot of 
time on this)





> On May 12, 2021, at 11:53 AM, Øyvind Teig  wrote:
> 
> I am not certain whether you start with Java and end up with describing a 
> possible implementation for Go, or stay with Java. In any case Java is your 
> starting point. 
> 
> I guess, comparing any feature of any language, from the outside, then the 
> feature comparison lists turn up. But since you brought in Java..:
> 
> Then I can just as well throw in the JCSP library's Alternative (=ALT, 
> =select) class [1]. And here is their description of the associated 
> Alternative type:
> By invoking one of the following methods, a process may passively wait for 
> one or more of the guards associated with an Alternative object to become 
> ready. The methods differ in the way they choose which guard to select in the 
> case when two or more guards are ready:
> 
> select 
> 
>  waits for one or more of the guards to become ready. If more than one become 
> ready, it makes an arbitrary choice between them (and corresponds to the 
> occam ALT).
> priSelect 
> 
>  also waits for one or more of the guards to become ready. However, if more 
> than one becomes ready, it chooses the first one listed (and corresponds to 
> the occam PRI ALT). Note: the use of priSelect between channel inputs and a 
> skip guard (at lowest priority) gives us a polling operation on the readiness 
> of those channels.
> fairSelect 
> 
>  also waits for one or more of the guards to become ready. If more than one 
> become ready, it prioritises its choice so that the guard it chose the last 
> time it was invoked has lowest priority this time. This corresponds to a 
> common occam idiom used for real-time applications. If fairSelect is used in 
> a loop, a ready guard has the guarantee that no other guard will be serviced 
> twice before it will be serviced. This enables an upper bound on service 
> times to be calculated and ensures that no ready guard can be indefinitely 
> starved.
> In that world Go would look like this (provided perhaps, it also supported 
> list type select guards):
> 
> select
> pri select
> fair select
> 
> [1] JCSP Alternative class 
> 
>  - I am not certain how much JCSP has been used. It's "beautiful" (my words). 
> Observe that they didn't make any GoCSP library..
> 
> ==
> Aside: After the above discussion in this thread I found what I searched for, 
> before I started it: a thread from 2012 [2]. Some déjà vu experience!
> 
> Is there any Go page with the rationale for having a single select type and 
> not the other select type(s)? Like [3] or [4]. If not, maybe a new paragraph 
> to [4]?
> 
> Øyvind
> 
> [2] Priority select in Go 
>  (2012)
> [3] Bell Labs and CSP Threads  by Russ Cox
> [4] Why build concurrency on the ideas of CSP? 
> 
> ==
> 
> onsdag 12. mai 2021 kl. 16:52:19 UTC+2 skrev Haddock:
> In addition to htq and ltq you have a third queue  into which you also insert 
> a token once one has been added to htq or ltp. The thread/goroutine that 
> serves htq, ltp, hq, lq is blocked by this additional queue. When it is 
> empty, htq and ltq are also empty. So when the goroutine is blocked it is 
> fine in this case. This sound like this could be it :-)
> 
> Well, coming to think of it just using a sempahore here for the third queue 
> consumes less memory: Just a counter that blocks the thread/goroutine once it 
> has reached 0. 
> 
> -- 
> You received this message because you are subscribed to 

Re: [go-nuts] TestSetuidEtc fails during test execution in a container

['Andrew G. Morgan' via golang-nuts]

Mea culpa. I clearly misread the capsh output.

There is a cap_setgid in there. Looking closer at the output the miscompare 
is there in the first line. The groups are listed in an unsorted order. 
That is not expected by the test. Let me see what is causing this to 
happen. I'll use the bug to investigate and document what I find.

Cheers

Andrew

On Wednesday, May 12, 2021 at 3:48:15 PM UTC-7 Andrew G. Morgan wrote:

> OK. I've filed this bug. If we want to go this route, please assign it to 
> me:
>
> https://github.com/golang/go/issues/46145
>
>
> On Wednesday, May 12, 2021 at 2:53:19 PM UTC-7 Ian Lance Taylor wrote:
>
>> On Wed, May 12, 2021 at 2:47 PM 'Andrew G. Morgan' via golang-nuts
>>  wrote:
>> >
>> >
>> > It looks like the CapBound here is non-default. That is, this container 
>> is running with non-default restrictions.
>> >
>> > $ /sbin/capsh --decode=0xa80425fb
>> > 
>> 0xa80425fb=cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap
>> >
>> > The environment appears to be denying cap_setgid - which is why the 
>> Setgroups() call is failing.
>> >
>> > Is adjusting that environmental choice possible?
>>
>> Alternatively, can the test code detect that those restrictions are
>> being applied, and skip the test in that case? That's our usual
>> pattern for tests that can't be run in some environments. Thanks.
>>
>> Ian
>>
>>
>> > On Wednesday, May 12, 2021 at 2:34:09 PM UTC-7 Ian Lance Taylor wrote:
>> >>
>> >> [ + agm ]
>> >>
>> >> On Wed, May 12, 2021 at 2:12 PM Kumar Srinivasan  
>> wrote:
>> >> >
>> >> > Hello,
>> >> >
>> >> > This is the first time I am posting to this group, apologies if this 
>> is the wrong forum.
>> >> >
>> >> > I am trying to build the go sources and test the built sources, so 
>> effectively I am running
>> >> > % cd go-source-dir/src && GOROOT_BOOTSTRAP=/BOOT_GO bash 
>> ./all.bash
>> >> > I am seeing this failure attached below when I build and test within 
>> a container.
>> >> > However I don't see this issue in a Virtual Machine running CentOS7.
>> >> >
>> >> > Appreciate any help or insights anyone can offer.
>> >> >
>> >> > Thanks
>> >> > Kumar Srinivasan
>> >> >
>> >> > % uname -a
>> >> >
>> >> > Linux 7bb298e4-71d7-4f5e-4d4c-d58ac8ce61ac 4.15.0-76-generic 
>> #86-Ubuntu SMP Fri Jan 17 17:24:28 UTC 2020 x86_64
>> >> >
>> >> > 
>> >> > --- FAIL: TestSetuidEtc (0.12s)
>> >> > syscall_linux_test.go:668: [6] "Setgroups([]int{0,1,2,3})" 
>> comparison: "/proc/32911/status" got:"Groups:\t1 2 3 0" want:"Groups:\t0 1 
>> 2 3" (bad) [pid=32911 file:'Name: syscall.test
>> >> > Umask: 0022
>> >> > State: S (sleeping)
>> >> > Tgid: 32911
>> >> > Ngid: 0
>> >> > Pid: 32911
>> >> > PPid: 10324
>> >> > TracerPid: 0
>> >> > Uid: 0 0 0 0
>> >> > Gid: 0 0 0 0
>> >> > FDSize: 64
>> >> > Groups: 1 2 3 0
>> >> > NStgid: 32911
>> >> > NSpid: 32911
>> >> > NSpgid: 7
>> >> > NSsid: 7
>> >> > VmPeak: 1092152 kB
>> >> > VmSize: 1034812 kB
>> >> > VmLck: 0 kB
>> >> > VmPin: 0 kB
>> >> > VmHWM: 5372 kB
>> >> > VmRSS: 5372 kB
>> >> > RssAnon: 1416 kB
>> >> > RssFile: 3956 kB
>> >> > RssShmem: 0 kB
>> >> > VmData: 169344 kB
>> >> > VmStk: 132 kB
>> >> > VmExe: 1384 kB
>> >> > VmLib: 1464 kB
>> >> > VmPTE: 140 kB
>> >> > VmSwap: 0 kB
>> >> > HugetlbPages: 0 kB
>> >> > CoreDumping: 0
>> >> > Threads: 8
>> >> > SigQ: 2/128577
>> >> > SigPnd: 
>> >> > ShdPnd: 
>> >> > SigBlk: 
>> >> > SigIgn: 0030
>> >> > SigCgt: fffdffc1feff
>> >> > CapInh: a80425fb
>> >> > CapPrm: a80425fb
>> >> > CapEff: a80425fb
>> >> > CapBnd: a80425fb
>> >> > CapAmb: 
>> >> > NoNewPrivs: 0
>> >> > Seccomp: 2
>> >> > Speculation_Store_Bypass: thread force mitigated
>> >> > Cpus_allowed: ff
>> >> > Cpus_allowed_list: 0-7
>> >> > Mems_allowed: 
>> ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,0001
>> >> > Mems_allowed_list: 0
>> >> > voluntary_ctxt_switches: 22
>> >> > nonvoluntary_ctxt_switches: 52
>> >> > ' Pid: 32911]
>> >> > FAIL
>> >> > FAIL syscall 0.724s
>> >> >
>> >> > 
>> >> >
>> >> > --
>> >> > 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...@googlegroups.com.
>> >> > To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/9675fc9a-75df-4253-9112-e85d3026a185n%40googlegroups.com
>> .
>> >
>> > --
>> > You received this message because you are subscribed to the Google 
>> Groups "golang-nuts" group.
>> > To unsubscribe from this group and 

[go-nuts] cancel method of timerCtx of context package

[qinggeer Bao]

In the cancel method of timerCtx type:

func (c *timerCtx) cancel(removeFromParent bool, err error) {
c.cancelCtx.cancel(false, err)
if removeFromParent {
// Remove this timerCtx from its parent cancelCtx's children.
removeChild(c.cancelCtx.Context, c)
}
c.mu.Lock()
if c.timer != nil {
c.timer.Stop()
c.timer = nil
}
c.mu.Unlock()
}

why it use the following:
c.cancelCtx.cancel(false, err)
if removeFromParent {
// Remove this timerCtx from its parent cancelCtx's children.
removeChild(c.cancelCtx.Context, c)
}

instead, direclty call 
c.cancelCtx.cancel(removeFromParent, err)

Is there any reason? 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b6ec3bd3-4f4e-4a8d-a43f-3a185b5f1ac9n%40googlegroups.com.

Re: [go-nuts] Fwd: protoc-gen-go and go modules

[Jim Idle]

Create a separate module that contains only the .proto files and use the
generate directive. You can then version that module and share it. If your
client is some other language, you can generate Its code from the same repo
at the same version using your CI. For instance generate a pip wheel as
well as the go source.

By checking in the generated code for all languages, you guarantee that it
is in a particular state and that your build is reproducible. It sounds
counter intuitive, but Makes sense once you've cogitated on it.

On Wed, May 12, 2021 at 18:47 Amit Saha  wrote:

> Hi all, this is only relevant to people using grpc.  I posted the query
> below to the grpc mailing list, thought of posting it here as welll.
>
> How are you importing the generated definitions and other resources
> them into your server and client? As far as I see it now, the protoc
> command will not generate a go.mod file in the generated code which
> means - you have to do it manually and then import them into your
> server and client. That is, you will have three modules:
>
> - One for server
> - One for client
> - One for the generated code
>
> This seems to be the cleanest approach. During local development, we
> will then use the "replace" directive for iteration.
>
> I am keen to hear how it's being done by others in the community.
>
> Thanks,
> Amit.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CANODV3kqN0wtK5bO3AfVbUhMt1iE9eYvboqbzmSLnY72N6-a6A%40mail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAGPPfg9MtU0yvgr9FOC-h9XCzpG7O2Sfm%3Dha53swxZiyd1uFrQ%40mail.gmail.com.

Re: [go-nuts] TestSetuidEtc fails during test execution in a container

['Andrew G. Morgan' via golang-nuts]

OK. I've filed this bug. If we want to go this route, please assign it to 
me:

https://github.com/golang/go/issues/46145


On Wednesday, May 12, 2021 at 2:53:19 PM UTC-7 Ian Lance Taylor wrote:

> On Wed, May 12, 2021 at 2:47 PM 'Andrew G. Morgan' via golang-nuts
>  wrote:
> >
> >
> > It looks like the CapBound here is non-default. That is, this container 
> is running with non-default restrictions.
> >
> > $ /sbin/capsh --decode=0xa80425fb
> > 
> 0xa80425fb=cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap
> >
> > The environment appears to be denying cap_setgid - which is why the 
> Setgroups() call is failing.
> >
> > Is adjusting that environmental choice possible?
>
> Alternatively, can the test code detect that those restrictions are
> being applied, and skip the test in that case? That's our usual
> pattern for tests that can't be run in some environments. Thanks.
>
> Ian
>
>
> > On Wednesday, May 12, 2021 at 2:34:09 PM UTC-7 Ian Lance Taylor wrote:
> >>
> >> [ + agm ]
> >>
> >> On Wed, May 12, 2021 at 2:12 PM Kumar Srinivasan  
> wrote:
> >> >
> >> > Hello,
> >> >
> >> > This is the first time I am posting to this group, apologies if this 
> is the wrong forum.
> >> >
> >> > I am trying to build the go sources and test the built sources, so 
> effectively I am running
> >> > % cd go-source-dir/src && GOROOT_BOOTSTRAP=/BOOT_GO bash 
> ./all.bash
> >> > I am seeing this failure attached below when I build and test within 
> a container.
> >> > However I don't see this issue in a Virtual Machine running CentOS7.
> >> >
> >> > Appreciate any help or insights anyone can offer.
> >> >
> >> > Thanks
> >> > Kumar Srinivasan
> >> >
> >> > % uname -a
> >> >
> >> > Linux 7bb298e4-71d7-4f5e-4d4c-d58ac8ce61ac 4.15.0-76-generic 
> #86-Ubuntu SMP Fri Jan 17 17:24:28 UTC 2020 x86_64
> >> >
> >> > 
> >> > --- FAIL: TestSetuidEtc (0.12s)
> >> > syscall_linux_test.go:668: [6] "Setgroups([]int{0,1,2,3})" 
> comparison: "/proc/32911/status" got:"Groups:\t1 2 3 0" want:"Groups:\t0 1 
> 2 3" (bad) [pid=32911 file:'Name: syscall.test
> >> > Umask: 0022
> >> > State: S (sleeping)
> >> > Tgid: 32911
> >> > Ngid: 0
> >> > Pid: 32911
> >> > PPid: 10324
> >> > TracerPid: 0
> >> > Uid: 0 0 0 0
> >> > Gid: 0 0 0 0
> >> > FDSize: 64
> >> > Groups: 1 2 3 0
> >> > NStgid: 32911
> >> > NSpid: 32911
> >> > NSpgid: 7
> >> > NSsid: 7
> >> > VmPeak: 1092152 kB
> >> > VmSize: 1034812 kB
> >> > VmLck: 0 kB
> >> > VmPin: 0 kB
> >> > VmHWM: 5372 kB
> >> > VmRSS: 5372 kB
> >> > RssAnon: 1416 kB
> >> > RssFile: 3956 kB
> >> > RssShmem: 0 kB
> >> > VmData: 169344 kB
> >> > VmStk: 132 kB
> >> > VmExe: 1384 kB
> >> > VmLib: 1464 kB
> >> > VmPTE: 140 kB
> >> > VmSwap: 0 kB
> >> > HugetlbPages: 0 kB
> >> > CoreDumping: 0
> >> > Threads: 8
> >> > SigQ: 2/128577
> >> > SigPnd: 
> >> > ShdPnd: 
> >> > SigBlk: 
> >> > SigIgn: 0030
> >> > SigCgt: fffdffc1feff
> >> > CapInh: a80425fb
> >> > CapPrm: a80425fb
> >> > CapEff: a80425fb
> >> > CapBnd: a80425fb
> >> > CapAmb: 
> >> > NoNewPrivs: 0
> >> > Seccomp: 2
> >> > Speculation_Store_Bypass: thread force mitigated
> >> > Cpus_allowed: ff
> >> > Cpus_allowed_list: 0-7
> >> > Mems_allowed: 
> ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,0001
> >> > Mems_allowed_list: 0
> >> > voluntary_ctxt_switches: 22
> >> > nonvoluntary_ctxt_switches: 52
> >> > ' Pid: 32911]
> >> > FAIL
> >> > FAIL syscall 0.724s
> >> >
> >> > 
> >> >
> >> > --
> >> > 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...@googlegroups.com.
> >> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/9675fc9a-75df-4253-9112-e85d3026a185n%40googlegroups.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...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/54f8ac32-f306-4bfd-bd8b-360f31b9415dn%40googlegroups.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.
To view this discussion on the web visit 

Re: [go-nuts] TestSetuidEtc fails during test execution in a container

[Ian Lance Taylor]

On Wed, May 12, 2021 at 2:47 PM 'Andrew G. Morgan' via golang-nuts
 wrote:
>
>
> It looks like the CapBound here is non-default. That is, this container is 
> running with non-default restrictions.
>
> $ /sbin/capsh --decode=0xa80425fb
> 0xa80425fb=cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap
>
> The environment appears to be denying cap_setgid - which is why the 
> Setgroups() call is failing.
>
> Is adjusting that environmental choice possible?

Alternatively, can the test code detect that those restrictions are
being applied, and skip the test in that case?  That's our usual
pattern for tests that can't be run in some environments.  Thanks.

Ian


> On Wednesday, May 12, 2021 at 2:34:09 PM UTC-7 Ian Lance Taylor wrote:
>>
>> [ + agm ]
>>
>> On Wed, May 12, 2021 at 2:12 PM Kumar Srinivasan  wrote:
>> >
>> > Hello,
>> >
>> > This is the first time I am posting to this group, apologies if this is 
>> > the wrong forum.
>> >
>> > I am trying to build the go sources and test the built sources, so 
>> > effectively I am running
>> > % cd go-source-dir/src && GOROOT_BOOTSTRAP=/BOOT_GO bash 
>> > ./all.bash
>> > I am seeing this failure attached below when I build and test within a 
>> > container.
>> > However I don't see this issue in a Virtual Machine running CentOS7.
>> >
>> > Appreciate any help or insights anyone can offer.
>> >
>> > Thanks
>> > Kumar Srinivasan
>> >
>> > % uname -a
>> >
>> > Linux 7bb298e4-71d7-4f5e-4d4c-d58ac8ce61ac 4.15.0-76-generic #86-Ubuntu 
>> > SMP Fri Jan 17 17:24:28 UTC 2020 x86_64
>> >
>> > 
>> > --- FAIL: TestSetuidEtc (0.12s)
>> > syscall_linux_test.go:668: [6] "Setgroups([]int{0,1,2,3})" comparison: 
>> > "/proc/32911/status" got:"Groups:\t1 2 3 0" want:"Groups:\t0 1 2 3" (bad) 
>> > [pid=32911 file:'Name: syscall.test
>> > Umask: 0022
>> > State: S (sleeping)
>> > Tgid: 32911
>> > Ngid: 0
>> > Pid: 32911
>> > PPid: 10324
>> > TracerPid: 0
>> > Uid: 0 0 0 0
>> > Gid: 0 0 0 0
>> > FDSize: 64
>> > Groups: 1 2 3 0
>> > NStgid: 32911
>> > NSpid: 32911
>> > NSpgid: 7
>> > NSsid: 7
>> > VmPeak: 1092152 kB
>> > VmSize: 1034812 kB
>> > VmLck: 0 kB
>> > VmPin: 0 kB
>> > VmHWM: 5372 kB
>> > VmRSS: 5372 kB
>> > RssAnon: 1416 kB
>> > RssFile: 3956 kB
>> > RssShmem: 0 kB
>> > VmData: 169344 kB
>> > VmStk: 132 kB
>> > VmExe: 1384 kB
>> > VmLib: 1464 kB
>> > VmPTE: 140 kB
>> > VmSwap: 0 kB
>> > HugetlbPages: 0 kB
>> > CoreDumping: 0
>> > Threads: 8
>> > SigQ: 2/128577
>> > SigPnd: 
>> > ShdPnd: 
>> > SigBlk: 
>> > SigIgn: 0030
>> > SigCgt: fffdffc1feff
>> > CapInh: a80425fb
>> > CapPrm: a80425fb
>> > CapEff: a80425fb
>> > CapBnd: a80425fb
>> > CapAmb: 
>> > NoNewPrivs: 0
>> > Seccomp: 2
>> > Speculation_Store_Bypass: thread force mitigated
>> > Cpus_allowed: ff
>> > Cpus_allowed_list: 0-7
>> > Mems_allowed: 
>> > ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,0001
>> > Mems_allowed_list: 0
>> > voluntary_ctxt_switches: 22
>> > nonvoluntary_ctxt_switches: 52
>> > ' Pid: 32911]
>> > FAIL
>> > FAIL syscall 0.724s
>> >
>> > 
>> >
>> > --
>> > 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...@googlegroups.com.
>> > To view this discussion on the web visit 
>> > https://groups.google.com/d/msgid/golang-nuts/9675fc9a-75df-4253-9112-e85d3026a185n%40googlegroups.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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/54f8ac32-f306-4bfd-bd8b-360f31b9415dn%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcU_O7neHnQw7siewYt8Cz2QFW7%2BL5VvidfPM_bQGU2efA%40mail.gmail.com.

Re: [go-nuts] TestSetuidEtc fails during test execution in a container

['Andrew G. Morgan' via golang-nuts]

It looks like the CapBound here is non-default. That is, this container is 
running with non-default restrictions.

$ /sbin/capsh --decode=0xa80425fb
0xa80425fb=cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap

The environment appears to be denying cap_setgid - which is why the 
Setgroups() call is failing.

Is adjusting that environmental choice possible?

Cheers

Andrew

On Wednesday, May 12, 2021 at 2:34:09 PM UTC-7 Ian Lance Taylor wrote:

> [ + agm ]
>
> On Wed, May 12, 2021 at 2:12 PM Kumar Srinivasan  
> wrote:
> >
> > Hello,
> >
> > This is the first time I am posting to this group, apologies if this is 
> the wrong forum.
> >
> > I am trying to build the go sources and test the built sources, so 
> effectively I am running
> > % cd go-source-dir/src && GOROOT_BOOTSTRAP=/BOOT_GO bash 
> ./all.bash
> > I am seeing this failure attached below when I build and test within a 
> container.
> > However I don't see this issue in a Virtual Machine running CentOS7.
> >
> > Appreciate any help or insights anyone can offer.
> >
> > Thanks
> > Kumar Srinivasan
> >
> > % uname -a
> >
> > Linux 7bb298e4-71d7-4f5e-4d4c-d58ac8ce61ac 4.15.0-76-generic #86-Ubuntu 
> SMP Fri Jan 17 17:24:28 UTC 2020 x86_64
> >
> > 
> > --- FAIL: TestSetuidEtc (0.12s)
> > syscall_linux_test.go:668: [6] "Setgroups([]int{0,1,2,3})" comparison: 
> "/proc/32911/status" got:"Groups:\t1 2 3 0" want:"Groups:\t0 1 2 3" (bad) 
> [pid=32911 file:'Name: syscall.test
> > Umask: 0022
> > State: S (sleeping)
> > Tgid: 32911
> > Ngid: 0
> > Pid: 32911
> > PPid: 10324
> > TracerPid: 0
> > Uid: 0 0 0 0
> > Gid: 0 0 0 0
> > FDSize: 64
> > Groups: 1 2 3 0
> > NStgid: 32911
> > NSpid: 32911
> > NSpgid: 7
> > NSsid: 7
> > VmPeak: 1092152 kB
> > VmSize: 1034812 kB
> > VmLck: 0 kB
> > VmPin: 0 kB
> > VmHWM: 5372 kB
> > VmRSS: 5372 kB
> > RssAnon: 1416 kB
> > RssFile: 3956 kB
> > RssShmem: 0 kB
> > VmData: 169344 kB
> > VmStk: 132 kB
> > VmExe: 1384 kB
> > VmLib: 1464 kB
> > VmPTE: 140 kB
> > VmSwap: 0 kB
> > HugetlbPages: 0 kB
> > CoreDumping: 0
> > Threads: 8
> > SigQ: 2/128577
> > SigPnd: 
> > ShdPnd: 
> > SigBlk: 
> > SigIgn: 0030
> > SigCgt: fffdffc1feff
> > CapInh: a80425fb
> > CapPrm: a80425fb
> > CapEff: a80425fb
> > CapBnd: a80425fb
> > CapAmb: 
> > NoNewPrivs: 0
> > Seccomp: 2
> > Speculation_Store_Bypass: thread force mitigated
> > Cpus_allowed: ff
> > Cpus_allowed_list: 0-7
> > Mems_allowed: 
> ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,0001
> > Mems_allowed_list: 0
> > voluntary_ctxt_switches: 22
> > nonvoluntary_ctxt_switches: 52
> > ' Pid: 32911]
> > FAIL
> > FAIL syscall 0.724s
> >
> > 
> >
> > --
> > 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...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/9675fc9a-75df-4253-9112-e85d3026a185n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/54f8ac32-f306-4bfd-bd8b-360f31b9415dn%40googlegroups.com.

Re: [go-nuts] TestSetuidEtc fails during test execution in a container

[Kumar Srinivasan]

Whoops, I missed mentioning I was trying to build and test this branch +
hash:

https://go.googlesource.com/go/+/fcee6b930a01407527e3a0386af2ea7ac4e66d44



Thanks
Kumar

On Wed, May 12, 2021 at 2:33 PM Ian Lance Taylor  wrote:

> [ + agm ]
>
> On Wed, May 12, 2021 at 2:12 PM Kumar Srinivasan 
> wrote:
> >
> > Hello,
> >
> > This is the first time I am posting to this group, apologies if this is
> the wrong forum.
> >
> > I am trying to build the go sources and test the built sources, so
> effectively I am running
> > % cd go-source-dir/src && GOROOT_BOOTSTRAP=/BOOT_GO bash
> ./all.bash
> > I am seeing this failure attached below when I build and test within a
> container.
> > However I don't see this issue in a Virtual Machine running CentOS7.
> >
> > Appreciate any help or insights anyone can offer.
> >
> > Thanks
> > Kumar Srinivasan
> >
> > % uname -a
> >
> > Linux 7bb298e4-71d7-4f5e-4d4c-d58ac8ce61ac 4.15.0-76-generic #86-Ubuntu
> SMP Fri Jan 17 17:24:28 UTC 2020 x86_64
> >
> > 
> > --- FAIL: TestSetuidEtc (0.12s)
> > syscall_linux_test.go:668: [6] "Setgroups([]int{0,1,2,3})" comparison:
> "/proc/32911/status" got:"Groups:\t1 2 3 0" want:"Groups:\t0 1 2 3" (bad)
> [pid=32911 file:'Name: syscall.test
> > Umask: 0022
> > State: S (sleeping)
> > Tgid: 32911
> > Ngid: 0
> > Pid: 32911
> > PPid: 10324
> > TracerPid: 0
> > Uid: 0 0 0 0
> > Gid: 0 0 0 0
> > FDSize: 64
> > Groups: 1 2 3 0
> > NStgid: 32911
> > NSpid: 32911
> > NSpgid: 7
> > NSsid: 7
> > VmPeak: 1092152 kB
> > VmSize: 1034812 kB
> > VmLck: 0 kB
> > VmPin: 0 kB
> > VmHWM: 5372 kB
> > VmRSS: 5372 kB
> > RssAnon: 1416 kB
> > RssFile: 3956 kB
> > RssShmem: 0 kB
> > VmData: 169344 kB
> > VmStk: 132 kB
> > VmExe: 1384 kB
> > VmLib: 1464 kB
> > VmPTE: 140 kB
> > VmSwap: 0 kB
> > HugetlbPages: 0 kB
> > CoreDumping: 0
> > Threads: 8
> > SigQ: 2/128577
> > SigPnd: 
> > ShdPnd: 
> > SigBlk: 
> > SigIgn: 0030
> > SigCgt: fffdffc1feff
> > CapInh: a80425fb
> > CapPrm: a80425fb
> > CapEff: a80425fb
> > CapBnd: a80425fb
> > CapAmb: 
> > NoNewPrivs: 0
> > Seccomp: 2
> > Speculation_Store_Bypass: thread force mitigated
> > Cpus_allowed: ff
> > Cpus_allowed_list: 0-7
> > Mems_allowed:
> ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,0001
> > Mems_allowed_list: 0
> > voluntary_ctxt_switches: 22
> > nonvoluntary_ctxt_switches: 52
> > ' Pid: 32911]
> > FAIL
> > FAIL syscall 0.724s
> >
> > 
> >
> > --
> > 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.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/9675fc9a-75df-4253-9112-e85d3026a185n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEXt0tRQPwv_9pwvETGBZR%2BtgNVY02Mh_dQBvmMh%2BwnroKAYCQ%40mail.gmail.com.

Re: [go-nuts] TestSetuidEtc fails during test execution in a container

[Ian Lance Taylor]

[ + agm ]

On Wed, May 12, 2021 at 2:12 PM Kumar Srinivasan  wrote:
>
> Hello,
>
> This is the first time I am posting to this group, apologies if this is the 
> wrong forum.
>
> I am trying to build the go sources and test the built sources, so 
> effectively I am running
> % cd go-source-dir/src && GOROOT_BOOTSTRAP=/BOOT_GO bash ./all.bash
> I am seeing this failure attached below when I build and test within a 
> container.
> However I don't see this issue in a Virtual Machine running CentOS7.
>
> Appreciate any help or insights anyone can offer.
>
> Thanks
> Kumar Srinivasan
>
> % uname -a
>
> Linux 7bb298e4-71d7-4f5e-4d4c-d58ac8ce61ac 4.15.0-76-generic #86-Ubuntu SMP 
> Fri Jan 17 17:24:28 UTC 2020 x86_64
>
> 
> --- FAIL: TestSetuidEtc (0.12s)
> syscall_linux_test.go:668: [6] "Setgroups([]int{0,1,2,3})" comparison: 
> "/proc/32911/status" got:"Groups:\t1 2 3 0" want:"Groups:\t0 1 2 3" (bad) 
> [pid=32911 file:'Name: syscall.test
> Umask: 0022
> State: S (sleeping)
> Tgid: 32911
> Ngid: 0
> Pid: 32911
> PPid: 10324
> TracerPid: 0
> Uid: 0 0 0 0
> Gid: 0 0 0 0
> FDSize: 64
> Groups: 1 2 3 0
> NStgid: 32911
> NSpid: 32911
> NSpgid: 7
> NSsid: 7
> VmPeak: 1092152 kB
> VmSize: 1034812 kB
> VmLck: 0 kB
> VmPin: 0 kB
> VmHWM: 5372 kB
> VmRSS: 5372 kB
> RssAnon: 1416 kB
> RssFile: 3956 kB
> RssShmem: 0 kB
> VmData: 169344 kB
> VmStk: 132 kB
> VmExe: 1384 kB
> VmLib: 1464 kB
> VmPTE: 140 kB
> VmSwap: 0 kB
> HugetlbPages: 0 kB
> CoreDumping: 0
> Threads: 8
> SigQ: 2/128577
> SigPnd: 
> ShdPnd: 
> SigBlk: 
> SigIgn: 0030
> SigCgt: fffdffc1feff
> CapInh: a80425fb
> CapPrm: a80425fb
> CapEff: a80425fb
> CapBnd: a80425fb
> CapAmb: 
> NoNewPrivs: 0
> Seccomp: 2
> Speculation_Store_Bypass: thread force mitigated
> Cpus_allowed: ff
> Cpus_allowed_list: 0-7
> Mems_allowed: 
> ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,0001
> Mems_allowed_list: 0
> voluntary_ctxt_switches: 22
> nonvoluntary_ctxt_switches: 52
> ' Pid: 32911]
> FAIL
> FAIL syscall 0.724s
>
> 
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/9675fc9a-75df-4253-9112-e85d3026a185n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUNzYvg08iVxaaUGK%3DtZf5h1d6kNj_0_cbQk0y2nU%3D70w%40mail.gmail.com.

[go-nuts] TestSetuidEtc fails during test execution in a container

[Kumar Srinivasan]

Hello,

This is the first time I am posting to this group, apologies if this is the 
wrong forum.

I am trying to build the go sources and test the built sources, so 
effectively I am running
% cd go-source-dir/src && GOROOT_BOOTSTRAP=/BOOT_GO bash 
./all.bash
I am seeing this failure attached below when I build and test within a 
container.
However I don't see this issue in a Virtual Machine running CentOS7.

Appreciate any help or insights anyone can offer.

Thanks
Kumar Srinivasan

% uname -a

Linux 7bb298e4-71d7-4f5e-4d4c-d58ac8ce61ac 4.15.0-76-generic #86-Ubuntu SMP 
Fri Jan 17 17:24:28 UTC 2020 x86_64

--- FAIL: TestSetuidEtc (0.12s)
syscall_linux_test.go:668: [6] "Setgroups([]int{0,1,2,3})" comparison: 
"/proc/32911/status" got:"Groups:\t1 2 3 0" want:"Groups:\t0 1 2 3" (bad) 
[pid=32911 file:'Name: syscall.test
Umask: 0022
State: S (sleeping)
Tgid: 32911
Ngid: 0
Pid: 32911
PPid: 10324
TracerPid: 0
Uid: 0 0 0 0
Gid: 0 0 0 0
FDSize: 64
Groups: 1 2 3 0 
NStgid: 32911
NSpid: 32911
NSpgid: 7
NSsid: 7
VmPeak: 1092152 kB
VmSize: 1034812 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 5372 kB
VmRSS: 5372 kB
RssAnon: 1416 kB
RssFile: 3956 kB
RssShmem: 0 kB
VmData: 169344 kB
VmStk: 132 kB
VmExe: 1384 kB
VmLib: 1464 kB
VmPTE: 140 kB
VmSwap: 0 kB
HugetlbPages: 0 kB
CoreDumping: 0
Threads: 8
SigQ: 2/128577
SigPnd: 
ShdPnd: 
SigBlk: 
SigIgn: 0030
SigCgt: fffdffc1feff
CapInh: a80425fb
CapPrm: a80425fb
CapEff: a80425fb
CapBnd: a80425fb
CapAmb: 
NoNewPrivs: 0
Seccomp: 2
Speculation_Store_Bypass: thread force mitigated
Cpus_allowed: ff
Cpus_allowed_list: 0-7
Mems_allowed: 
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,0001
Mems_allowed_list: 0
voluntary_ctxt_switches: 22
nonvoluntary_ctxt_switches: 52
' Pid: 32911]
FAIL
FAIL syscall 0.724s



-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9675fc9a-75df-4253-9112-e85d3026a185n%40googlegroups.com.

Re: [go-nuts] defer and Go memory model

[Jan Mercl]

On Wed, May 12, 2021 at 7:55 PM Ge  wrote:

> Do you mean in following case if anthoer goroutine is observing A and B,
> there is no possbility that A is 0 and B is 5? (assuming no other 
> synchronization here)
>
> ```
> var A, B int
> func try() {
> defer func() { B = 5 }
> A = 3
> }

There's no synchronization in this code, so other goroutines  reading
A or B w/o said synchronization may observe any values. Stalled,
changing in wrong order, random..., you name it.

But if has nothing to do with defer. The particular code is equal to

var A, B int
func try() {
 A = 3
 B = 5
}

with the set of problems as the version using defer.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-VMhaQgVTd%3D45Quh94GjFh9xeKzxn-K3BnGd5GwG9ygdg%40mail.gmail.com.

Re: [go-nuts] defer and Go memory model

['Axel Wagner' via golang-nuts]

If we assume no other synchronization here, you have concurrent
modification of variables, which is undefined behavior.

But to answer your original questions: Yes, the behavior of `defer` is
included in the clause "the order expressed by the program" - "the order
specified by the program" doesn't mean "lexical order". `defer` is no
different in that regard than assigning a function literal to a variable
and calling it at a later point - the execution still happens at a later
point, even if the statements in the function literal appear lexically
before the call.

So, yes `defer` implies happens-before relationships: Every return
statement in the function happens-before the deferred execution, which
happens-before the function call returns.

On Wed, May 12, 2021 at 7:56 PM Ge  wrote:

> Thank you Jan, sorry for my bad english.
> Do you mean in following case if anthoer goroutine is observing A and B,
> there is no possbility that A is 0 and B is 5? (assuming no other
> synchronization here)
>
> ```
> var A, B int
> func try() {
> defer func() { B = 5 }
> A = 3
> }
>
> Ge
>
> 在2021年5月12日星期三 UTC+8 下午10:48:43 写道：
>
>> On Wed, May 12, 2021 at 4:38 PM Ge  wrote:
>> >
>> > According to https://golang.org/ref/spec#Defer_statements there is
>> such an expression:
>> > `A "defer" statement invokes a function whose execution is deferred to
>> the moment the surrounding function returns`
>> >
>> > Does `defer` ensure happens-before behaviour with non-defer code?
>>
>> Happens before talks/defines properties/behavior of concurrently
>> executing goroutines. The deferred function is executed in the same
>> goroutine as its surrounding function. Any HB relations wrt other
>> goroutines are the same as if the deferred function was not deferred
>> but explicitly called before just returning from the surrounding
>> function.
>>
>> > However x86 allows out-of-order execution happening across function
>> calls,
>>
>> OOE and other peculiar CPU tricks should not be observable by the Go
>> program, modulo some side channel attacks.
>>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/2bf8beb9-1927-4311-9c7c-32f880bded79n%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHJXtPtMcS8NHVpGqs3q210fJfii55XkknqWfWiowKQpw%40mail.gmail.com.

Re: [go-nuts] defer and Go memory model

[Ge]

Thank you Jan, sorry for my bad english.
Do you mean in following case if anthoer goroutine is observing A and B, 
there is no possbility that A is 0 and B is 5? (assuming no other 
synchronization here)

```
var A, B int
func try() {
defer func() { B = 5 }
A = 3
}

Ge

在2021年5月12日星期三 UTC+8 下午10:48:43 写道：

> On Wed, May 12, 2021 at 4:38 PM Ge  wrote:
> >
> > According to https://golang.org/ref/spec#Defer_statements there is such 
> an expression:
> > `A "defer" statement invokes a function whose execution is deferred to 
> the moment the surrounding function returns`
> >
> > Does `defer` ensure happens-before behaviour with non-defer code?
>
> Happens before talks/defines properties/behavior of concurrently
> executing goroutines. The deferred function is executed in the same
> goroutine as its surrounding function. Any HB relations wrt other
> goroutines are the same as if the deferred function was not deferred
> but explicitly called before just returning from the surrounding
> function.
>
> > However x86 allows out-of-order execution happening across function 
> calls,
>
> OOE and other peculiar CPU tricks should not be observable by the Go
> program, modulo some side channel attacks.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2bf8beb9-1927-4311-9c7c-32f880bded79n%40googlegroups.com.

[go-nuts] Re: Still "missing" priority or ordered select in go?

[Øyvind Teig]

I am not certain whether you start with Java and end up with describing a 
possible implementation for Go, or stay with Java. In any case Java is your 
starting point. 

I guess, comparing any feature of any language, from the outside, then the 
feature comparison lists turn up. But since you brought in Java..:

Then I can just as well throw in the JCSP library's Alternative (=ALT, 
=select) class [1]. And here is their description of the associated 
Alternative type:

*By invoking one of the following methods, a process may passively wait for 
one or more of the guards associated with an Alternative object to become 
ready. The methods differ in the way they choose which guard to select in 
the case when two or more guards are ready:*

   - *select 
   

 waits 
   for one or more of the guards to become ready. If more than one become 
   ready, it makes an arbitrary choice between them (and corresponds to 
   the occam ALT).*
   - *priSelect 
   

 also 
   waits for one or more of the guards to become ready. However, if more than 
   one becomes ready, it chooses the first one listed (and corresponds to 
   the occam PRI ALT). Note: the use of priSelect between channel inputs and a 
   skip guard (at lowest priority) gives us a polling operation on 
   the readiness of those channels.*
   - *fairSelect 
   

 also 
   waits for one or more of the guards to become ready. If more than one 
   become ready, it prioritises its choice so that the guard it chose the last 
   time it was invoked has lowest priority this time. This corresponds to a 
   common occam idiom used for real-time applications. If fairSelect is used 
   in a loop, a ready guard has the guarantee that no other guard will be 
   serviced twice before it will be serviced. This enables an upper bound on 
   service times to be calculated and ensures that no ready guard can be 
   indefinitely starved.*

In that world Go would look like this (provided perhaps, it also supported 
list type select guards):

*select*
*pri select*
*fair select*

[1] JCSP Alternative class 

 - 
I am not certain how much JCSP has been used. It's "beautiful" (my words). 
Observe that they didn't make any GoCSP library..

*==*
*Aside*: After the above discussion in this thread I found what I searched 
for, before I started it: a thread from 2012 [2]. Some *déjà vu *experience!

Is there any Go page with the rationale for having a single select type and 
not the other select type(s)? Like [3] or [4]. If not, maybe a new 
paragraph to [4]?

Øyvind

[2] Priority select in Go 
 (2012)
[3] Bell Labs and CSP Threads  by Russ Cox
[4] Why build concurrency on the ideas of CSP? 

*==*

onsdag 12. mai 2021 kl. 16:52:19 UTC+2 skrev Haddock:

> In addition to htq and ltq you have a third queue  into which you also 
>> insert a token once one has been added to htq or ltp. The thread/goroutine 
>> that serves htq, ltp, hq, lq is blocked by this additional queue. When it 
>> is empty, htq and ltq are also empty. So when the goroutine is blocked it 
>> is fine in this case. This sound like this could be it :-)
>>
>
> Well, coming to think of it just using a sempahore here for the third 
> queue consumes less memory: Just a counter that blocks the thread/goroutine 
> once it has reached 0. 
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ceeff584-7108-455d-b825-1f3845971134n%40googlegroups.com.

[go-nuts] Re: proposal: ignore stale information in go list -find -json

[Manlio Perillo]

I was suggesting to not use work.Builder in the go list command, even in 
case the -json flag is specified or the -f flag contains the ".Stale" 
string.

I'm not sure about the -f flag, however, since it is an explicit request 
from the user.  On the other hand, if the user specified the -find flag, 
probably don't really want expensive data.

As for the -json flag, it may be considered a change to the public API, but 
I'm not sure.

Thanks.

On Wednesday, May 12, 2021 at 4:49:04 PM UTC+2 Bryan C. Mills wrote:

> https://golang.org/issue/29666 (still open) is the general issue for 
> avoiding unnecessary work in 'go list'.
>
> It isn't obvious to me which kind of stale information we can omit for 'go 
> list -find' in particular.
>
> On Wednesday, May 12, 2021 at 4:11:14 AM UTC-4 manlio@gmail.com wrote:
>
>> The go list `-find` flag was introduced to skip resolving imports.
>> However, is it really necessary to include stale information in this case?
>> Does `golang.org/x/tools/go/package` 
>>  need it?
>>
>> Getting stale information is not a trivial work, AFAIK.
>> Is it ok to change the meaning of an existing flag?
>>
>> Thanks
>> Manlio
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/620f9cd1-4209-41c5-a3c3-a77c3854384dn%40googlegroups.com.

Re: [go-nuts] proposal: infer module name via version control when running `go mod init`

[Jon Calhoun]

Sounds like this functionality was removed intentionally and will be a
no-go then. Thanks for sharing the link Jay!

On Wed, May 12, 2021 at 11:19 AM Jay Conrod  wrote:

> The go command used to infer the module path from .git/config for github
> origins specifically. However, that was removed in 1.13, based on
> discussion in #27951 . It
> wasn't a strong enough signal, and since it's important to get the module
> path right early on, it seemed better to require that the path be set
> explicitly when it can't be inferred from the location within $GOPATH/src.
>
> On Wed, May 12, 2021 at 11:01 AM Jon Calhoun  wrote:
>
>> I suspect that the VCS path gives nearly the same level of confidence in
>> practice. My personal experience shows that it is pretty rare for the two
>> not to line up, and when it does the developer made a conscious decision to
>> do so and knows to work around it.
>>
>> I'm also not suggesting that we remove existing behavior. go mod init
>>  is still valid so we don't lose robustness there.
>>
>>
>> On Wednesday, May 12, 2021 at 10:42:29 AM UTC-4 Bryan C. Mills wrote:
>>
>>> go mod init should only infer a module path when it can be certain that
>>> path is correct.
>>>
>>> For packages already stored in GOPATH/src, it knows the correct path
>>> with high confidence: the path relative to GOPATH/src is the path by which
>>> the packages in the module are imported when in GOPATH mode, so it is safe
>>> to assume the same path in module mode.
>>>
>>> On the other hand, a module hosted at a particular VCS path can be
>>> served through an arbitrarily different path using go-import
>>>  metadata
>>> , and it could also be a private
>>> fork intended for use only with a replace directive
>>>  (or intended to
>>> temporarily host a change while an upstream PR is outstanding). So we
>>> cannot assume that the VCS path necessarily corresponds to the module path
>>> — it seems more robust to ask the user to supply the intended path
>>> explicitly.
>>>
>>> On Wednesday, May 12, 2021 at 9:25:48 AM UTC-4 jonca...@gmail.com wrote:
>>>
 After more thought, the proposal should be altered to only support git
 in the first pass. It would cover a majority of users, wouldn't affect the
 experience in other VCS, and would simplify the initial implementation.

 Doing every VCS at once would require someone learning how every VCS
 defines the default remote repository (if it even does), and building off
 that. It would be better to do each individually and let someone familiar
 with each VCS take charge of that specific PR using existing VCS
 implementations as a pattern to follow.
 On Wednesday, May 12, 2021 at 7:28:11 AM UTC-4 ohir wrote:

> Dnia 2021-05-11, o godz. 11:14:24
> Jon Calhoun  napisał(a):
>
> > it saves me a handful of keystrokes at best - so I understand if it
> doesn't seem
> > worth the effort.
>
> Right.
>
> > It feels close enough to the current behavior to be a good addition
>
> Gopath is retiring soon. Anyway, Someone needs to do many more
> keystrokes
> to int repository anyway.
>
> > , but I admittedly haven't explored how easy/hard it would be to
> implement.
>
> Look at the list of currently supported VCSes to get a feel of the
> task.
> For the starter: infer module name from a Fossil's checkout file (it
> is a sqlite db).
>
> Hoe this helps
>
> > Best,
> > Jon
>
> --
> Wojciech S. Czarnecki
> << ^oo^ >> OHIR-RIPE
>
 --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/7beb2ab6-940c-451c-bee6-45ccf73ad8edn%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CADScuBTfsYurSa9KXzNerEhH2XsJZJ1MNzTmAkZSCNLO_Qu1jQ%40mail.gmail.com.

Re: [go-nuts] proposal: infer module name via version control when running `go mod init`

['Jay Conrod' via golang-nuts]

The go command used to infer the module path from .git/config for github
origins specifically. However, that was removed in 1.13, based on
discussion in #27951 . It wasn't
a strong enough signal, and since it's important to get the module path
right early on, it seemed better to require that the path be set explicitly
when it can't be inferred from the location within $GOPATH/src.

On Wed, May 12, 2021 at 11:01 AM Jon Calhoun  wrote:

> I suspect that the VCS path gives nearly the same level of confidence in
> practice. My personal experience shows that it is pretty rare for the two
> not to line up, and when it does the developer made a conscious decision to
> do so and knows to work around it.
>
> I'm also not suggesting that we remove existing behavior. go mod init
>  is still valid so we don't lose robustness there.
>
>
> On Wednesday, May 12, 2021 at 10:42:29 AM UTC-4 Bryan C. Mills wrote:
>
>> go mod init should only infer a module path when it can be certain that
>> path is correct.
>>
>> For packages already stored in GOPATH/src, it knows the correct path with
>> high confidence: the path relative to GOPATH/src is the path by which the
>> packages in the module are imported when in GOPATH mode, so it is safe to
>> assume the same path in module mode.
>>
>> On the other hand, a module hosted at a particular VCS path can be served
>> through an arbitrarily different path using go-import
>>  metadata
>> , and it could also be a private
>> fork intended for use only with a replace directive
>>  (or intended to
>> temporarily host a change while an upstream PR is outstanding). So we
>> cannot assume that the VCS path necessarily corresponds to the module path
>> — it seems more robust to ask the user to supply the intended path
>> explicitly.
>>
>> On Wednesday, May 12, 2021 at 9:25:48 AM UTC-4 jonca...@gmail.com wrote:
>>
>>> After more thought, the proposal should be altered to only support git
>>> in the first pass. It would cover a majority of users, wouldn't affect the
>>> experience in other VCS, and would simplify the initial implementation.
>>>
>>> Doing every VCS at once would require someone learning how every VCS
>>> defines the default remote repository (if it even does), and building off
>>> that. It would be better to do each individually and let someone familiar
>>> with each VCS take charge of that specific PR using existing VCS
>>> implementations as a pattern to follow.
>>> On Wednesday, May 12, 2021 at 7:28:11 AM UTC-4 ohir wrote:
>>>
 Dnia 2021-05-11, o godz. 11:14:24
 Jon Calhoun  napisał(a):

 > it saves me a handful of keystrokes at best - so I understand if it
 doesn't seem
 > worth the effort.

 Right.

 > It feels close enough to the current behavior to be a good addition

 Gopath is retiring soon. Anyway, Someone needs to do many more
 keystrokes
 to int repository anyway.

 > , but I admittedly haven't explored how easy/hard it would be to
 implement.

 Look at the list of currently supported VCSes to get a feel of the
 task.
 For the starter: infer module name from a Fossil's checkout file (it is
 a sqlite db).

 Hoe this helps

 > Best,
 > Jon

 --
 Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

>>> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/7beb2ab6-940c-451c-bee6-45ccf73ad8edn%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAGCADba09WLXZ%3D9oYK9OiZFNQ7%2BU_PUaJtNra0mK6KzK%2BDfOtw%40mail.gmail.com.

Re: [go-nuts] proposal: infer module name via version control when running `go mod init`

[Jon Calhoun]

I suspect that the VCS path gives nearly the same level of confidence in 
practice. My personal experience shows that it is pretty rare for the two 
not to line up, and when it does the developer made a conscious decision to 
do so and knows to work around it.

I'm also not suggesting that we remove existing behavior. go mod init  is still valid so we don't lose robustness there.


On Wednesday, May 12, 2021 at 10:42:29 AM UTC-4 Bryan C. Mills wrote:

> go mod init should only infer a module path when it can be certain that 
> path is correct.
>
> For packages already stored in GOPATH/src, it knows the correct path with 
> high confidence: the path relative to GOPATH/src is the path by which the 
> packages in the module are imported when in GOPATH mode, so it is safe to 
> assume the same path in module mode.
>
> On the other hand, a module hosted at a particular VCS path can be served 
> through an arbitrarily different path using go-import 
>  metadata 
> , and it could also be a private 
> fork intended for use only with a replace directive 
>  (or intended to 
> temporarily host a change while an upstream PR is outstanding). So we 
> cannot assume that the VCS path necessarily corresponds to the module path 
> — it seems more robust to ask the user to supply the intended path 
> explicitly.
>
> On Wednesday, May 12, 2021 at 9:25:48 AM UTC-4 jonca...@gmail.com wrote:
>
>> After more thought, the proposal should be altered to only support git in 
>> the first pass. It would cover a majority of users, wouldn't affect the 
>> experience in other VCS, and would simplify the initial implementation.
>>
>> Doing every VCS at once would require someone learning how every VCS 
>> defines the default remote repository (if it even does), and building off 
>> that. It would be better to do each individually and let someone familiar 
>> with each VCS take charge of that specific PR using existing VCS 
>> implementations as a pattern to follow.
>> On Wednesday, May 12, 2021 at 7:28:11 AM UTC-4 ohir wrote:
>>
>>> Dnia 2021-05-11, o godz. 11:14:24 
>>> Jon Calhoun  napisał(a): 
>>>
>>> > it saves me a handful of keystrokes at best - so I understand if it 
>>> doesn't seem 
>>> > worth the effort. 
>>>
>>> Right. 
>>>
>>> > It feels close enough to the current behavior to be a good addition 
>>>
>>> Gopath is retiring soon. Anyway, Someone needs to do many more 
>>> keystrokes 
>>> to int repository anyway. 
>>>
>>> > , but I admittedly haven't explored how easy/hard it would be to 
>>> implement. 
>>>
>>> Look at the list of currently supported VCSes to get a feel of the task. 
>>> For the starter: infer module name from a Fossil's checkout file (it is 
>>> a sqlite db). 
>>>
>>> Hoe this helps 
>>>
>>> > Best, 
>>> > Jon 
>>>
>>> -- 
>>> Wojciech S. Czarnecki 
>>> << ^oo^ >> OHIR-RIPE 
>>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7beb2ab6-940c-451c-bee6-45ccf73ad8edn%40googlegroups.com.

[go-nuts] Re: Still "missing" priority or ordered select in go?

[Haddock]

> In addition to htq and ltq you have a third queue  into which you also 
> insert a token once one has been added to htq or ltp. The thread/goroutine 
> that serves htq, ltp, hq, lq is blocked by this additional queue. When it 
> is empty, htq and ltq are also empty. So when the goroutine is blocked it 
> is fine in this case. This sound like this could be it :-)
>

Well, coming to think of it just using a sempahore here for the third queue 
consumes less memory: Just a counter that blocks the thread/goroutine once 
it has reached 0. 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/29d45dcd-eb01-481b-b896-256d5209b1fdn%40googlegroups.com.

[go-nuts] Re: proposal: ignore stale information in go list -find -json

['Bryan C. Mills' via golang-nuts]

https://golang.org/issue/29666 (still open) is the general issue for 
avoiding unnecessary work in 'go list'.

It isn't obvious to me which kind of stale information we can omit for 'go 
list -find' in particular.

On Wednesday, May 12, 2021 at 4:11:14 AM UTC-4 manlio@gmail.com wrote:

> The go list `-find` flag was introduced to skip resolving imports.
> However, is it really necessary to include stale information in this case?
> Does `golang.org/x/tools/go/package` 
>  need it?
>
> Getting stale information is not a trivial work, AFAIK.
> Is it ok to change the meaning of an existing flag?
>
> Thanks
> Manlio
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/aa38de4b-cfe8-4e15-9288-fd9ab50f8d55n%40googlegroups.com.

Re: [go-nuts] defer and Go memory model

[Jan Mercl]

On Wed, May 12, 2021 at 4:38 PM Ge  wrote:
>
> According to https://golang.org/ref/spec#Defer_statements there is such an 
> expression:
>   `A "defer" statement invokes a function whose execution is deferred to the 
> moment the surrounding function returns`
>
> Does `defer` ensure  happens-before behaviour with non-defer code?

Happens before talks/defines properties/behavior of concurrently
executing goroutines. The deferred function is executed in the same
goroutine as its surrounding function. Any HB relations wrt other
goroutines are the same as if the deferred function was not deferred
but explicitly called before just returning from the surrounding
function.

> However x86 allows out-of-order execution happening across function calls,

OOE and other peculiar CPU tricks should not be observable by the Go
program, modulo some side channel attacks.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-Um%3DTL3Qy00f8znvZyHPTUJ2WnHX31mpUu2BH4tUQWJ5g%40mail.gmail.com.

Re: [go-nuts] proposal: infer module name via version control when running `go mod init`

['Bryan C. Mills' via golang-nuts]

go mod init should only infer a module path when it can be certain that 
path is correct.

For packages already stored in GOPATH/src, it knows the correct path with 
high confidence: the path relative to GOPATH/src is the path by which the 
packages in the module are imported when in GOPATH mode, so it is safe to 
assume the same path in module mode.

On the other hand, a module hosted at a particular VCS path can be served 
through an arbitrarily different path using go-import 
 metadata 
, and it could also be a private fork 
intended for use only with a replace directive 
 (or intended to 
temporarily host a change while an upstream PR is outstanding). So we 
cannot assume that the VCS path necessarily corresponds to the module path 
— it seems more robust to ask the user to supply the intended path 
explicitly.

On Wednesday, May 12, 2021 at 9:25:48 AM UTC-4 jonca...@gmail.com wrote:

> After more thought, the proposal should be altered to only support git in 
> the first pass. It would cover a majority of users, wouldn't affect the 
> experience in other VCS, and would simplify the initial implementation.
>
> Doing every VCS at once would require someone learning how every VCS 
> defines the default remote repository (if it even does), and building off 
> that. It would be better to do each individually and let someone familiar 
> with each VCS take charge of that specific PR using existing VCS 
> implementations as a pattern to follow.
> On Wednesday, May 12, 2021 at 7:28:11 AM UTC-4 ohir wrote:
>
>> Dnia 2021-05-11, o godz. 11:14:24 
>> Jon Calhoun  napisał(a): 
>>
>> > it saves me a handful of keystrokes at best - so I understand if it 
>> doesn't seem 
>> > worth the effort. 
>>
>> Right. 
>>
>> > It feels close enough to the current behavior to be a good addition 
>>
>> Gopath is retiring soon. Anyway, Someone needs to do many more keystrokes 
>> to int repository anyway. 
>>
>> > , but I admittedly haven't explored how easy/hard it would be to 
>> implement. 
>>
>> Look at the list of currently supported VCSes to get a feel of the task. 
>> For the starter: infer module name from a Fossil's checkout file (it is a 
>> sqlite db). 
>>
>> Hoe this helps 
>>
>> > Best, 
>> > Jon 
>>
>> -- 
>> Wojciech S. Czarnecki 
>> << ^oo^ >> OHIR-RIPE 
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/68fd2648-fe99-42e1-9bd9-24150e9c6310n%40googlegroups.com.

[go-nuts] defer and Go memory model

[Ge]

According to https://golang.org/ref/spec#Defer_statements there is such an 
expression:
 * `A "defer" statement invokes a function whose execution is deferred to 
the moment the surrounding function returns`*

Does `defer` ensure  happens-before behaviour with non-defer code?
I have read https://golang.org/ref/mem but got nothing except this.
(It seems not clear to me about the meaning of `the order expressed by the 
program*`.*)

  `Within a single goroutine, the happens-before order is the order 
expressed by the program.`

In following case what I know is ③ happens before ①, 
but what about ②? Is it possible that ② is executed after
③ and ①?

```Go

var A, B, C int

func main() {
defer func()  { A = 4 } //①
B = 5 //②
defer func()   { C = 6 }   //③
}
```

Appendix:
1. The background: 
I was digging into the implementation of sync.Once and 
wonder if `defer atomic.StoreUint32(, 1)` in 
function doSlow could be replaced with `defer func() {o.done = 1}`.
```
func (o *Once) Do(f func()) {
  if atomic.LoadUint32() == 0 { 
o.doSlow(f)
  }
}

func (o *Once) doSlow(f func()) {
  o.m.Lock()
  defer o.m.Unlock()
  if o.done == 0 {
defer atomic.StoreUint32(, 1)
f()
  }
}
```

2. As I know, `defer` is implemented by inserting corresponding 
function calling before any exiting point(Eg. in x86 the ret 
instruction).

However x86 allows out-of-order execution happening across function 
calls,
and I'm not sure if it will happen in this case(f() and o.done has no 
dependency 
with each other so it is possible?).
If anyone knows I would appreciate for your clarification.

Thanks for your time.

Ge


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/bf1987cf-2c06-46e3-bbc1-be91fb0f11een%40googlegroups.com.

[go-nuts] Re: go mod vendor without updating packages

['Bryan C. Mills' via golang-nuts]

Module dependencies are transitive. 'go mod edit' edits the syntax of the 
go.mod file, but does not ensure that the resulting transitive dependencies 
are consistent.

To adjust your dependencies, use 'go get -d' instead of 'go mod edit':
go get -d google.golang.org/grpc@v1.29.1

That will downgrade or remove other dependencies as needed so that the 
requested version is actually what is selected.
On Tuesday, May 11, 2021 at 2:44:46 PM UTC-4 Sankar wrote:

> Hi,
>
> I have some packages with some versions in my `go.mod` including some 
> indirect dependencies that are needed by some of my direct dependencies. In 
> this, there is a particular version of grpc that I want to use (and not the 
> latest).
>
> I add the specific version of grpc I want by:
>
> go mod edit -require=google.golang.org/gr...@v1.29.1 
> 
>
> which correctly updates the `go.mod` file. But when I run the `go mod 
> vendor` next, this grpc line gets deleted and the latest of grpc is fetched 
> again. How do I enforce and vendor a particular version of an indirect 
> dependency ?
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8c79cc09-74e3-4f4d-b4f7-1b661a8ea806n%40googlegroups.com.

Re: [go-nuts] proposal: infer module name via version control when running `go mod init`

[Jon Calhoun]

After more thought, the proposal should be altered to only support git in 
the first pass. It would cover a majority of users, wouldn't affect the 
experience in other VCS, and would simplify the initial implementation.

Doing every VCS at once would require someone learning how every VCS 
defines the default remote repository (if it even does), and building off 
that. It would be better to do each individually and let someone familiar 
with each VCS take charge of that specific PR using existing VCS 
implementations as a pattern to follow.
On Wednesday, May 12, 2021 at 7:28:11 AM UTC-4 ohir wrote:

> Dnia 2021-05-11, o godz. 11:14:24
> Jon Calhoun  napisał(a):
>
> > it saves me a handful of keystrokes at best - so I understand if it 
> doesn't seem
> > worth the effort.
>
> Right.
>
> > It feels close enough to the current behavior to be a good addition
>
> Gopath is retiring soon. Anyway, Someone needs to do many more keystrokes
> to int repository anyway. 
>
> > , but I admittedly haven't explored how easy/hard it would be to 
> implement.
>
> Look at the list of currently supported VCSes to get a feel of the task.
> For the starter: infer module name from a Fossil's checkout file (it is a 
> sqlite db).
>
> Hoe this helps
>
> > Best,
> > Jon
>
> -- 
> Wojciech S. Czarnecki
> << ^oo^ >> OHIR-RIPE
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/132f8177-26ff-47c3-ab0a-1502db42fbf3n%40googlegroups.com.

Re: [go-nuts] proposal: infer module name via version control when running `go mod init`

[Wojciech S. Czarnecki]

Dnia 2021-05-11, o godz. 11:14:24
Jon Calhoun  napisał(a):

> it saves me a handful of keystrokes at best - so I understand if it doesn't 
> seem
> worth the effort.

Right.

> It feels close enough to the current behavior to be a good addition

Gopath is retiring soon. Anyway, Someone needs to do many more keystrokes
to int repository anyway. 

> , but I admittedly haven't explored how easy/hard it would be to implement.

Look at the list of currently supported VCSes to get a feel of the task.
For the starter: infer module name from a Fossil's checkout file (it is a 
sqlite db).
 
Hoe this helps

> Best,
> Jon

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20210512132732.0bfc4867%40xmint.

[go-nuts] Re: Still "missing" priority or ordered select in go?

[Haddock]

Brian Candler schrieb am Mittwoch, 12. Mai 2021 um 10:34:31 UTC+2:

> On Wednesday, 12 May 2021 at 08:40:36 UTC+1 Haddock wrote:
>
>> I once implemented something to solve the same problem in Java. So I have 
>> a high priority queue (hq) and a low priority queue (lq). Whenever an item 
>> is atted to the hq a token is also added to some associated high priority 
>> token queue (htq). Same for the lq and ltq.
>>
>> Some thread or goroutine takes tokens from the htq as long as in contains 
>> tokens. You can add a count so that after any n tokens taken from the htq 
>> the ltq is checked whether it contains a token.
>>
>> Works fine until both, htp and ltp, are empty. You don't want to iterate 
>> over htp and ltp all the time till one contains a token again. So I 
>> introduced a semaphore on which the thread serving all these queues would 
>> be blocked till htq ot ltq recevie a new token.
>>
>> I thought that the sempahore would slow things down. So I did 
>> measurements with a bare bone concurrent queue and the priority queue. The 
>> difference in time to serve n tokens in htq and m tokens in ltq was very 
>> small also for high values of n and m.
>>
>
> I think you'll enjoy this video by Rob Pike:
> https://www.youtube.com/watch?v=5zXAHh5tJqQ
>
> Great ways to handle this stuff robustly using Go channels instead of 
> low-level synchronization primatives like semaphores.  First time watching, 
> I had to keep my finger on the pause button to make sure I understood each 
> screenful of code before he moved on :-)
>

In addition to htq and ltq you have a third queue  into which you also 
insert a token once one has been added to htq or ltp. The thread/goroutine 
that serves htq, ltp, hq, lq is blocked by this additional queue. When it 
is empty, htq and ltq are also empty. So when the goroutine is blocked it 
is fine in this case. This sound like this could be it :-)

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f0c33314-20aa-4842-a489-68c3c71d446dn%40googlegroups.com.

[go-nuts] Fwd: protoc-gen-go and go modules

[Amit Saha]

Hi all, this is only relevant to people using grpc.  I posted the query
below to the grpc mailing list, thought of posting it here as welll.

How are you importing the generated definitions and other resources
them into your server and client? As far as I see it now, the protoc
command will not generate a go.mod file in the generated code which
means - you have to do it manually and then import them into your
server and client. That is, you will have three modules:

- One for server
- One for client
- One for the generated code

This seems to be the cleanest approach. During local development, we
will then use the "replace" directive for iteration.

I am keen to hear how it's being done by others in the community.

Thanks,
Amit.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CANODV3kqN0wtK5bO3AfVbUhMt1iE9eYvboqbzmSLnY72N6-a6A%40mail.gmail.com.

[go-nuts] Re: Still "missing" priority or ordered select in go?

[Brian Candler]

On Wednesday, 12 May 2021 at 08:40:36 UTC+1 Haddock wrote:

> I once implemented something to solve the same problem in Java. So I have 
> a high priority queue (hq) and a low priority queue (lq). Whenever an item 
> is atted to the hq a token is also added to some associated high priority 
> token queue (htq). Same for the lq and ltq.
>
> Some thread or goroutine takes tokens from the htq as long as in contains 
> tokens. You can add a count so that after any n tokens taken from the htq 
> the ltq is checked whether it contains a token.
>
> Works fine until both, htp and ltp, are empty. You don't want to iterate 
> over htp and ltp all the time till one contains a token again. So I 
> introduced a semaphore on which the thread serving all these queues would 
> be blocked till htq ot ltq recevie a new token.
>
> I thought that the sempahore would slow things down. So I did measurements 
> with a bare bone concurrent queue and the priority queue. The difference in 
> time to serve n tokens in htq and m tokens in ltq was very small also for 
> high values of n and m.
>

I think you'll enjoy this video by Rob Pike:
https://www.youtube.com/watch?v=5zXAHh5tJqQ

Great ways to handle this stuff robustly using Go channels instead of 
low-level synchronization primatives like semaphores.  First time watching, 
I had to keep my finger on the pause button to make sure I understood each 
screenful of code before he moved on :-)

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a4c340b5-a576-4dbd-a973-679fd5b98812n%40googlegroups.com.

[go-nuts] proposal: ignore stale information in go list -find -json

[Manlio Perillo]

The go list `-find` flag was introduced to skip resolving imports.
However, is it really necessary to include stale information in this case?
Does `golang.org/x/tools/go/package` need it?

Getting stale information is not a trivial work, AFAIK.
Is it ok to change the meaning of an existing flag?

Thanks
Manlio

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/950f4081-5c11-4e1e-9986-97989d95a5f0n%40googlegroups.com.

[go-nuts] Re: Still "missing" priority or ordered select in go?

[Haddock]

I once implemented something to solve the same problem in Java. So I have a 
high priority queue (hq) and a low priority queue (lq). Whenever an item is 
atted to the hq a token is also added to some associated high priority 
token queue (htq). Same for the lq and ltq.

Some thread or goroutine takes tokens from the htq as long as in contains 
tokens. You can add a count so that after any n tokens taken from the htq 
the ltq is checked whether it contains a token.

Works fine until both, htp and ltp, are empty. You don't want to iterate 
over htp and ltp all the time till one contains a token again. So I 
introduced a semaphore on which the thread serving all these queues would 
be blocked till htq ot ltq recevie a new token.

I thought that the sempahore would slow things down. So I did measurements 
with a bare bone concurrent queue and the priority queue. The difference in 
time to serve n tokens in htq and m tokens in ltq was very small also for 
high values of n and m.

oyvin...@teigfam.net schrieb am Donnerstag, 29. April 2021 um 10:51:43 
UTC+2:

> I know from some years ago that go did not have any priority or ordered 
> select construct [1].
>
> The idea is that select always is a nondeterministic choice operator, if 
> this is still so. Implemented with a random, I assume.
>
> Programming user defined "fair" algorithms or patterns is then not 
> possible, I believe.
>
> Is this still so in Go? No prioritised or ordered select in go?
>
> But is there still a way to code this by f.ex. combining several selects? 
> I saw a different take at this at [2], where the select is replaced a 
> single chan containing a chan bundle, thus becoming "deterministic".
>
> [1] Blog note Nondeterminism 
>  
> (disclaimer: 
> no ads, no gifts, only fun and expenses)
>
> [2] “A pattern for overcoming non-determinism of Golang select statement 
> 
>  (3May2019) 
> by Pedram Hajesmaeeli
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/bb6cbb5c-e240-4207-a5b1-5e7cfdd4dd64n%40googlegroups.com.