Re: [go-nuts] A little weird thing in using finalizer

[Brian Candler]

On Saturday, 25 April 2020 06:35:22 UTC+1, T L wrote:
>
> Why is each of the finalizers called twice?
>


Isn't it just printed once in main and once in finalizer?
https://play.golang.org/p/7aY9NA1AFNa

-- 
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/86e3714f-95fc-4cdd-a6ca-57e2dd240dc6%40googlegroups.com.

Re: [go-nuts] A little weird thing in using finalizer

[T L]

With time.Sleep, it always prints:

> 31
> 37
> 47
> 47
> 37
> 31
>

Why is each of the finalizers called twice?

On Saturday, April 25, 2020 at 1:08:43 AM UTC-4, Ian Lance Taylor wrote:
>
> On Fri, Apr 24, 2020 at 9:30 PM T L > 
> wrote: 
> > 
> > The following program might print: 
> > 
> >> 31 
> >> 37 
> >> 47 
> >> 47 
> >> 37 
> >> 31 
> > 
> > 
> > or 
> > 
> >> 31 
> >> 37 
> >> 47 
> >> 47 
> > 
> > 
> > but with the highest possibility to print 
> > 
> >> 31 
> >> 37 
> >> 47 
> > 
> > 
> > Is not normal? 
> > 
> > 
> > package main 
> > 
> > import ( 
> > "fmt" 
> > "math/rand" 
> > "runtime" 
> > "time" 
> > "unsafe" 
> > ) 
> > 
> > type Foo struct { 
> > x int 
> > a int 
> > } 
> > 
> > func main() { 
> > for i := 0; i < 3; i++ { 
> > f := NewFoo(i) 
> > println(f.a) 
> > } 
> > 
> > runtime.GC() 
> > 
> > time.After(time.Second) 
> > } 
> > 
> > func do(i *uint) { 
> > runtime.SetFinalizer(i, func(f *uint) { 
> > fmt.Println(*f) 
> > }) 
> > } 
> > 
> > //go:noinline 
> > func NewFoo(i int) *Foo { 
> > f := {a: rand.Intn(50)} 
> > 
> > do((*uint)(unsafe.Pointer())) 
> > 
> > return f 
> > } 
>
> Finalizers are not guaranteed to run. 
>
> That said, I'm not sure why you are calling time.After.  That doesn't 
> make finalizers any more likely to run.  You'll probably see fairly 
> reliable results if you change that to call time.Sleep instead. 
>
> Ian 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/68c17055-b1ed-4b26-a6d2-63c02e1d8ea0%40googlegroups.com.

Re: [go-nuts] A little weird thing in using finalizer

[Ian Lance Taylor]

On Fri, Apr 24, 2020 at 9:30 PM T L  wrote:
>
> The following program might print:
>
>> 31
>> 37
>> 47
>> 47
>> 37
>> 31
>
>
> or
>
>> 31
>> 37
>> 47
>> 47
>
>
> but with the highest possibility to print
>
>> 31
>> 37
>> 47
>
>
> Is not normal?
>
>
> package main
>
> import (
> "fmt"
> "math/rand"
> "runtime"
> "time"
> "unsafe"
> )
>
> type Foo struct {
> x int
> a int
> }
>
> func main() {
> for i := 0; i < 3; i++ {
> f := NewFoo(i)
> println(f.a)
> }
>
> runtime.GC()
>
> time.After(time.Second)
> }
>
> func do(i *uint) {
> runtime.SetFinalizer(i, func(f *uint) {
> fmt.Println(*f)
> })
> }
>
> //go:noinline
> func NewFoo(i int) *Foo {
> f := {a: rand.Intn(50)}
>
> do((*uint)(unsafe.Pointer()))
>
> return f
> }

Finalizers are not guaranteed to run.

That said, I'm not sure why you are calling time.After.  That doesn't
make finalizers any more likely to run.  You'll probably see fairly
reliable results if you change that to call time.Sleep instead.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcW4U90dkpDi6%2B2tdU83LhRXiPSnrCPWrB87G%3DkK1Enh_A%40mail.gmail.com.

[go-nuts] A little weird thing in using finalizer

[T L]

The following program might print:

31
> 37
> 47
> 47
> 37
> 31
>

or 

31
> 37
> 47
> 47
>

but with the highest possibility to print

31
> 37
> 47
>

Is not normal?


package main

import (
"fmt"
"math/rand"
"runtime"
"time"
"unsafe"
)

type Foo struct {
x int
a int
}

func main() {
for i := 0; i < 3; i++ {
f := NewFoo(i)
println(f.a)
}

runtime.GC()

time.After(time.Second)
}

func do(i *uint) {
runtime.SetFinalizer(i, func(f *uint) {
fmt.Println(*f)
})
}

//go:noinline
func NewFoo(i int) *Foo {
f := {a: rand.Intn(50)}

do((*uint)(unsafe.Pointer()))

return f
}

-- 
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/db59b870-b9c7-4411-a461-5857eb7017e2%40googlegroups.com.

Re: [go-nuts] terminating goruntime internal threads

[Ian Lance Taylor]

On Fri, Apr 24, 2020 at 3:39 AM Pavan  wrote:
>
> how do we terminate the go generated internal OS threads.  I am debugging an 
> issue , where  RES(memory resdent size)  size of. a process increases as 
> goroutines used increases.
> Iam trying to reduce the threads footprint contribution of process RES , 
> hence.  terminate the additional threads once go routines are completed.
>
> Is there an explicit call, I can make to terminate these processes.
>
> For the OS threads because of C functions calls, I am doing LockOSThread and 
> skipping unlock, so that they terminate as goroutine terminates.
>
> I see some discussion of this here:
> https://github.com/golang/go/issues/14592
> but could not find if an explicit call was introduced for application to call 
> terminate.

The trick using LockOSThread and returning from the function is
currently the only way to remove an existing thread.  In general the
Go runtime assumes that if you needed a thread once, you might need it
again at some point.

If your memory usage increases without bound, it's fairly unlikely
that the problem is the number of threads.  It's much more likely that
you have a memory leak in your Go program.  Use the heap profiler.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVuZq5yOCPcfXFfLm5a3JVd4nVL_RjK-%3DxiMfRJe1Z-fg%40mail.gmail.com.

Re: [go-nuts] Re: Why does for-range behaves differently depend on the slice's struc size?

[Ian Lance Taylor]

On Fri, Apr 24, 2020 at 1:32 PM Yulrizka  wrote:
>
> Most definitely interesting. 
> https://golang.org/src/cmd/compile/internal/ssa/rewriteAMD64.go#L54447
> Am I correct to assume that DUFFCOPY is and optimization for MOVE?
>
> If so, i wonder why the first example did not generate any MOV command at all.

In the first case, there was a move, but it was discarded in the SSA
pass because it was dead.

I would guess that the SSA pass is not smart enough to see that the
call to the builtin function is dead, so it doesn't remove it.

If I'm right, it's basically a missing optimization in the compiler.
But it doesn't seem like a very important one; not many people write
range loops that name the value but don't use it.

Ian


> On Friday, April 24, 2020 at 4:25:51 PM UTC+2, Tamás Gulácsi wrote:
>>
>> 2020. április 24., péntek 14:26:08 UTC+2 időpontban Yulrizka a következőt 
>> írta:
>>>
>>> Hello,
>>>
>>>
>>> I was playing around with this code
>>>
>>> main_var.go
>>> package main
>>>
>>> func main() {
>>> const size = 100
>>>
>>> slice := make([]SomeStruct, size)
>>> for _, s := range slice { // line 7
>>> _ = s
>>> }
>>>
>>> }
>>>
>>>
>>> type_small.go
>>> package main
>>>
>>> type SomeStruct struct {
>>> ID0 int64
>>> ID1 int64
>>> ID2 int64
>>> ID3 int64
>>> ID4 int64
>>> ID5 int64
>>> ID6 int64
>>> ID7 int64
>>> ID8 int64
>>> }
>>>
>>>
>>> I noted that if i added anoteher 64 bit int64 `ID9` (total of 10 * 8 byte = 
>>> 80 byte) integer to the struct, the for-loop becomes slower.
>>> And if I compare the assembly, it added instruction to copy the element
>>>
>>> // with 9 int64 (72 bytes)
>>> 0x001d 00029 (main_var.go:6)LEAQtype."".SomeStruct(SB), AX
>>> 0x0024 00036 (main_var.go:6)MOVQAX, (SP)
>>> 0x0028 00040 (main_var.go:6)MOVQ$100, 8(SP)
>>> 0x0031 00049 (main_var.go:6)MOVQ$100, 16(SP)
>>> 0x003a 00058 (main_var.go:6)CALLruntime.makeslice(SB)
>>> 0x003f 00063 (main_var.go:6)XORLAX, AX
>>> 0x0041 00065 (main_var.go:7)INCQAX
>>> 0x0044 00068 (main_var.go:7)CMPQAX, $100
>>> 0x004a 00074 (main_var.go:7)JLT65
>>> 0x004c 00076 (main_var.go:7)MOVQ32(SP), BP
>>> 0x0051 00081 (main_var.go:7)ADDQ$40, SP
>>> 0x0055 00085 (main_var.go:7)RET
>>> 0x0056 00086 (main_var.go:7)NOP
>>> 0x0056 00086 (main_var.go:3)CALLruntime.morestack_noctxt(SB)
>>> 0x005b 00091 (main_var.go:3)JMP0
>>>
>>> // with 10 int64 (80 bytes), it added DUFFCOPY instruction
>>> 0x001d 00029 (main_var.go:6)LEAQtype."".SomeStruct(SB), AX
>>> 0x0024 00036 (main_var.go:6)MOVQAX, (SP)
>>> 0x0028 00040 (main_var.go:6)MOVQ$100, 8(SP)
>>> 0x0031 00049 (main_var.go:6)MOVQ$100, 16(SP)
>>> 0x003a 00058 (main_var.go:6)CALLruntime.makeslice(SB)
>>> 0x003f 00063 (main_var.go:6)MOVQ24(SP), AX
>>> 0x0044 00068 (main_var.go:6)XORLCX, CX
>>> 0x0046 00070 (main_var.go:7)JMP76
>>> 0x0048 00072 (main_var.go:7)ADDQ$80, AX
>>> 0x004c 00076 (main_var.go:7)LEAQ""..autotmp_7+32(SP), DI
>>> 0x0051 00081 (main_var.go:7)MOVQAX, SI
>>> 0x0054 00084 (main_var.go:7)DUFFCOPY$826 # <-- copy the element
>>> 0x0067 00103 (main_var.go:7)INCQCX
>>> 0x006a 00106 (main_var.go:7)CMPQCX, $100
>>> 0x0071 00113 (main_var.go:7)JLT72
>>> 0x0073 00115 (main_var.go:7)MOVQ112(SP), BP
>>> 0x0078 00120 (main_var.go:7)ADDQ$120, SP
>>> 0x007c 00124 (main_var.go:7)RET
>>> 0x007d 00125 (main_var.go:7)NOP
>>> 0x007d 00125 (main_var.go:3)CALLruntime.morestack_noctxt(SB)
>>> 0x0082 00130 (main_var.go:3)JMP0
>>>
>>>
>>> I am just curious to why the bahavior is different on larger struct (> 80 
>>> bytes) even though in both cases the element of the slice is not being use.
>>>
>>> Thank you
>>
>>
>> After grepping the sources for DUFFCOPY,  
>> ./cmd/compile/internal/ssa/rewriteAMD64.go suggests that it is a DUFFCOPY 
>> before SSA rewrites it to something faster - and this is a size-depending 
>> operation.
>>
>> But I may be totally wrong...
>
> --
> 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/19743410-e4c6-4ca2-aee9-a0ba59afc4df%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] A modest format suggestion

[Ian Lance Taylor]

On Fri, Apr 24, 2020 at 12:32 PM Scott Deerwester
 wrote:
>
> I greatly appreciate the fact that Go has a coding standard. I have a modest 
> proposed modification. Instead of this:
>
> // Great is a really great function.
> func Great(
> anArg int, // This explains anArg
> anotherArg string, // This explains anotherArg
> ) (err error) {
> ...
>
> I'd think that this:
>
> // Great is a really great function.
> func Great(
> anArg  int,// This explains anArg
> anotherArg string, // This explains anotherArg
> ) (err error) {
> ...
>
>
> would be both clearer and more consistent with this:
>
> var (
> aVar   = 12  // This explains aVar
> anotherVar = "something" // This explains anotherVar
> )
>
>
> or this:
>
> type SomeStruct struct {
> FieldName string
> Value int
> }
>
>
> var aStructList = []*SomeStruct {
> {
> FieldName: "SomeName", // Comment for FieldName
> Value: 12, // Comment for Value
> },
> }
>
> which are already part of the standard coding style. Is this the right place 
> to make such a proposal?

There is a fairly high bar for gofmt changes these days, but it's not
possible.  The right approach is to discuss it here, and then if there
is some kind of consensus follow the proposal process outlined at
https://golang.org/s/proposal.  Thanks.

One useful metric would be look at some real Go code (that you didn't
write) and how often people use this style.  I suspect it's pretty
rare in the standard library.  One problem with this style is that (I
think) the argument comments don't show up in godoc, which makes them
hard to discover by people who just want to use the package.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWbF7FUmVG5rhgaipzMG6c-tCZHDETwdHpkh_z5sTSkLQ%40mail.gmail.com.

Re: [go-nuts] A modest format suggestion

[scott]

I think that these are independent questions. While I agree entirely with 
your comments on avoiding lots of parameters, and bundling them in a struct 
if it gets out of hand, helping clarity is of value whether no matter how 
many arguments there are. By analogy:

var aStructList = []*SomeStruct {
{
FieldName: "SomeName", // Comment for FieldName
Value: 12, // Comment for Value
},
}

and

var aStructList = []*SomeStruct {
// Comment about the following entry
{ FieldName: "SomeName", Value: 12 },
}

or

var aStructList = []*SomeStruct {
{ FieldName: "SomeName", Value: 12 }, // Comment about the entry on 
this line
}

are both perfectly fine (aren't they?).

On Friday, April 24, 2020 at 4:15:46 PM UTC-4, Saied Seghatoleslami wrote:
>
> Doesn't this style of writing assume that there are a lot of arguments to 
> be passed to function which I think is not a good practice since it makes 
> it much harder to remember what the function does and how to call and most 
> importantly, how to debug it when becomes necessary?
>
> So, if there are a lot of arguments to be passed to the function, it is 
> best to redesign it and use a data structure that encapsulates the 
> arguments.  Otherwise, what is wrong with this?
>
>
> // Great is a really great function anArg does this and anotherArg does 
> that.
> func Great(anArg int, anotherArg string) (err error) {
> return nil
> }
>
> On Fri, Apr 24, 2020 at 3:32 PM Scott Deerwester  > wrote:
>
>> I greatly appreciate the fact that Go has a coding standard. I have a 
>> modest proposed modification. Instead of this:
>>
>> // Great is a really great function.
>> func Great(
>> anArg int, // This explains anArg
>> anotherArg string, // This explains anotherArg
>> ) (err error) {
>> ...
>>
>> I'd think that this:
>>
>> // Great is a really great function.
>> func Great(
>> anArg  int,// This explains anArg
>> anotherArg string, // This explains anotherArg
>> ) (err error) {
>> ...
>>
>>
>> would be both clearer and more consistent with this:
>>
>> var (
>> aVar   = 12  // This explains aVar
>> anotherVar = "something" // This explains anotherVar
>> )
>>
>>
>> or this:
>>
>> type SomeStruct struct {
>> FieldName string
>> Value int
>> }
>>
>>
>> var aStructList = []*SomeStruct {
>> {
>> FieldName: "SomeName", // Comment for FieldName
>> Value: 12, // Comment for Value
>> },
>> }
>>
>> which are already part of the standard coding style. Is this the right 
>> place to make such a proposal?
>>
>> -- 
>> 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 golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/8a4fa305-a8bc-4512-8f23-6a42b479dd2d%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/3a0222c1-2063-4c64-a828-40e8e689ba33%40googlegroups.com.

[go-nuts] Re: Why does for-range behaves differently depend on the slice's struc size?

[Yulrizka]

Most definitely interesting. 
https://golang.org/src/cmd/compile/internal/ssa/rewriteAMD64.go#L54447 
Am I correct to assume that DUFFCOPY is and optimization for MOVE?

If so, i wonder why the first example did not generate any MOV command at 
all.

On Friday, April 24, 2020 at 4:25:51 PM UTC+2, Tamás Gulácsi wrote:
>
> 2020. április 24., péntek 14:26:08 UTC+2 időpontban Yulrizka a következőt 
> írta:
>>
>> Hello, 
>>
>>
>> I was playing around with this code 
>>
>> main_var.go
>> package main
>>
>> func main() {
>> const size = 100
>>
>> slice := make([]SomeStruct, size)
>> for _, s := range slice { // line 7
>> _ = s
>> }
>>
>> }
>>
>>
>> type_small.go
>> package main
>>
>> type SomeStruct struct {
>> ID0 int64
>> ID1 int64
>> ID2 int64
>> ID3 int64
>> ID4 int64
>> ID5 int64
>> ID6 int64
>> ID7 int64
>> ID8 int64
>> }
>>
>>
>> I noted that if i added anoteher 64 bit int64 `ID9` (total of 10 * 8 byte 
>> = 80 byte) integer to the struct, the for-loop becomes slower.
>> And if I compare the assembly, it added instruction to copy the element
>>
>> // with 9 int64 (72 bytes)
>> 0x001d 00029 (main_var.go:6)LEAQtype."".SomeStruct(SB), AX
>> 0x0024 00036 (main_var.go:6)MOVQAX, (SP)
>> 0x0028 00040 (main_var.go:6)MOVQ$100, 8(SP)
>> 0x0031 00049 (main_var.go:6)MOVQ$100, 16(SP)
>> 0x003a 00058 (main_var.go:6)CALLruntime.makeslice(SB)
>> 0x003f 00063 (main_var.go:6)XORLAX, AX
>> 0x0041 00065 (main_var.go:7)INCQAX
>> 0x0044 00068 (main_var.go:7)CMPQAX, $100
>> 0x004a 00074 (main_var.go:7)JLT65
>> 0x004c 00076 (main_var.go:7)MOVQ32(SP), BP
>> 0x0051 00081 (main_var.go:7)ADDQ$40, SP
>> 0x0055 00085 (main_var.go:7)RET
>> 0x0056 00086 (main_var.go:7)NOP
>> 0x0056 00086 (main_var.go:3)CALLruntime.morestack_noctxt(SB)
>> 0x005b 00091 (main_var.go:3)JMP0
>>
>> // with 10 int64 (80 bytes), it added DUFFCOPY instruction
>> 0x001d 00029 (main_var.go:6)LEAQtype."".SomeStruct(SB), AX
>> 0x0024 00036 (main_var.go:6)MOVQAX, (SP)
>> 0x0028 00040 (main_var.go:6)MOVQ$100, 8(SP)
>> 0x0031 00049 (main_var.go:6)MOVQ$100, 16(SP)
>> 0x003a 00058 (main_var.go:6)CALLruntime.makeslice(SB)
>> 0x003f 00063 (main_var.go:6)MOVQ24(SP), AX
>> 0x0044 00068 (main_var.go:6)XORLCX, CX
>> 0x0046 00070 (main_var.go:7)JMP76
>> 0x0048 00072 (main_var.go:7)ADDQ$80, AX
>> 0x004c 00076 (main_var.go:7)LEAQ""..autotmp_7+32(SP), DI
>> 0x0051 00081 (main_var.go:7)MOVQAX, SI
>> 0x0054 00084 (main_var.go:7)DUFFCOPY$826 # <-- copy the 
>> element
>> 0x0067 00103 (main_var.go:7)INCQCX
>> 0x006a 00106 (main_var.go:7)CMPQCX, $100
>> 0x0071 00113 (main_var.go:7)JLT72
>> 0x0073 00115 (main_var.go:7)MOVQ112(SP), BP
>> 0x0078 00120 (main_var.go:7)ADDQ$120, SP
>> 0x007c 00124 (main_var.go:7)RET
>> 0x007d 00125 (main_var.go:7)NOP
>> 0x007d 00125 (main_var.go:3)CALLruntime.morestack_noctxt(SB)
>> 0x0082 00130 (main_var.go:3)JMP0
>>
>>
>> I am just curious to why the bahavior is different on larger struct (> 80 
>> bytes) even though in both cases the element of the slice is not being use.
>>
>> Thank you
>>
>
> After grepping the sources for DUFFCOPY,  
> ./cmd/compile/internal/ssa/rewriteAMD64.go suggests that it is a DUFFCOPY 
> before SSA rewrites it to something faster - and this is a size-depending 
> operation.
>
> But I may be totally wrong...
>

-- 
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/19743410-e4c6-4ca2-aee9-a0ba59afc4df%40googlegroups.com.

Re: [go-nuts] A modest format suggestion

[Saied Seghatoleslami]

Doesn't this style of writing assume that there are a lot of arguments to
be passed to function which I think is not a good practice since it makes
it much harder to remember what the function does and how to call and most
importantly, how to debug it when becomes necessary?

So, if there are a lot of arguments to be passed to the function, it is
best to redesign it and use a data structure that encapsulates the
arguments.  Otherwise, what is wrong with this?


// Great is a really great function anArg does this and anotherArg does
that.
func Great(anArg int, anotherArg string) (err error) {
return nil
}

On Fri, Apr 24, 2020 at 3:32 PM Scott Deerwester 
wrote:

> I greatly appreciate the fact that Go has a coding standard. I have a
> modest proposed modification. Instead of this:
>
> // Great is a really great function.
> func Great(
> anArg int, // This explains anArg
> anotherArg string, // This explains anotherArg
> ) (err error) {
> ...
>
> I'd think that this:
>
> // Great is a really great function.
> func Great(
> anArg  int,// This explains anArg
> anotherArg string, // This explains anotherArg
> ) (err error) {
> ...
>
>
> would be both clearer and more consistent with this:
>
> var (
> aVar   = 12  // This explains aVar
> anotherVar = "something" // This explains anotherVar
> )
>
>
> or this:
>
> type SomeStruct struct {
> FieldName string
> Value int
> }
>
>
> var aStructList = []*SomeStruct {
> {
> FieldName: "SomeName", // Comment for FieldName
> Value: 12, // Comment for Value
> },
> }
>
> which are already part of the standard coding style. Is this the right
> place to make such a proposal?
>
> --
> 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/8a4fa305-a8bc-4512-8f23-6a42b479dd2d%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/CAOdwK1k%3DFf82EG91njLq37ybvQZA_Hq0KmPBG%2B1FW_CYF3h1Xg%40mail.gmail.com.

[go-nuts] A modest format suggestion

[Scott Deerwester]

I greatly appreciate the fact that Go has a coding standard. I have a 
modest proposed modification. Instead of this:

// Great is a really great function.
func Great(
anArg int, // This explains anArg
anotherArg string, // This explains anotherArg
) (err error) {
...

I'd think that this:

// Great is a really great function.
func Great(
anArg  int,// This explains anArg
anotherArg string, // This explains anotherArg
) (err error) {
...


would be both clearer and more consistent with this:

var (
aVar   = 12  // This explains aVar
anotherVar = "something" // This explains anotherVar
)


or this:

type SomeStruct struct {
FieldName string
Value int
}


var aStructList = []*SomeStruct {
{
FieldName: "SomeName", // Comment for FieldName
Value: 12, // Comment for Value
},
}

which are already part of the standard coding style. Is this the right 
place to make such a proposal?

-- 
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/8a4fa305-a8bc-4512-8f23-6a42b479dd2d%40googlegroups.com.

[go-nuts] Hey Gophers, we have an exiting job offer for you as Senior Go Developer (remote)!

[Amelie S.]

*Senior Golang Developer*

 

*LOCATION: REMOTE (within Europe)*

 

If you love databases, distributed systems,and Go this might be a great 
match.

We are looking for smart, dedicated and experienced Back-End engineers to 
join vChain and help us build an Open Source immutable Database (
https://github.com/codenotary/immudb). Most of the code is written in Go, 
so if you write exemplary code and know Golang inside out, you’ll feel like 
home. That said, you will be surrounded by experienced gophers that are 
keen to work with you.

 

vChain is the well-funded startup behind CodeNotary 
, the leading Open Source trust solution which 
delivers authenticity and provenance for digital objects. CodeNotary today 
already processes over 10 million code and container authentications every 
single month. 

 

*Qualifications*

·   Master's degree in Computer Science or EE

·   7+ years of professional experience in developing at a startup

·   Expert level programming skills in Golang (5+ years daily coding 
experience)

*·   **Experience in developing databases or key-value Stores (e. g. 
Reddis, MongoDB, Dgraph)*

·   Experience developing API driven architectures (e.g. REST, gRPC)

·   Great team skills


Apply today! 

-- 
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/c1826e32-96ea-45a1-8b9c-06a7130852b3%40googlegroups.com.

Re: [go-nuts] Why isn't there "number plus" postfix syntax for more than or equal?

[Scott Pakin]

On Friday, April 24, 2020 at 8:44:46 AM UTC-6, Michael Jones wrote:
>
> That feels clearer to me. Both concepts are now made explicit. The 
> language Pascal has ranges and a membership clause. ADA also embraced some 
> of it. We could imagine:
>
> a in 99..
> a in 99..123
>
> The “in” part feels important to me. 
>

Python's chained comparison operators are arguably more compatible with the 
existing Go syntax and semantics, though:

99 <= a <= 128

— Scott

-- 
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/2ee97826-38a2-4dec-8d94-73559020301d%40googlegroups.com.

Re: [go-nuts] Is the following funciton always safe to convert a string to a slice?

[T L]

For the first example, I always thought the "runtime.KeepAlive" call is 
essential before.
But after reading the explanations from Bryan C. Mills on Slack, I changed 
my mind now.

Bryan C. Mills said: The GC tracks pointers through their original 
allocations — the pointer scan does not care about lexical types, only 
allocation types.

On Tuesday, April 21, 2020 at 8:11:49 PM UTC-4, Ian Lance Taylor wrote:
>
> On Tue, Apr 21, 2020 at 6:49 AM T L > 
> wrote: 
> > 
> > func String2ByteSlice(str string) (bs []byte) { 
> > strHdr := (*reflect.StringHeader)(unsafe.Pointer()) 
> > sliceHdr := (*reflect.SliceHeader)(unsafe.Pointer()) 
> > 
> > // Is it possible that the str value is allocated on stack 
> > // and the stack grows at this moment, so the address value 
> > // stored in strHdr.Data will become obsoleted? 
> > 
> > sliceHdr.Data = strHdr.Data 
> > sliceHdr.Len = strHdr.Len 
> > sliceHdr.Cap = strHdr.Len 
> > 
> > runtime.KeepAlive() 
> > 
> > return 
> > } 
>
> Since you are correctly using *reflect.StringHeader, it doesn't matter 
> whether the stack is copied at that moment.  You are pointing at the 
> actual string value, so the pointer will be adjusted.  As far as I can 
> see, this is safe.  (Of course, it's not safe if somebody modifies the 
> contents of the returned []byte.) 
>
> Ian 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/83712696-b845-4db1-acdc-34b15b50baf4%40googlegroups.com.

Re: [go-nuts] Why isn't there "number plus" postfix syntax for more than or equal?

[Michael Jones]

Hi “Anon”,

A more serious answer (though just personal opinion) is that your idea
lacks the “grammar” that it implies.

Value Relationship Value “a >= 99”

is a “sentence” or fragment in most computer languages. It is a logical
assertion that is either true or false and can be composed into larger
sentences in that grammar.

99 <= a && a <= 123

What your “value range” notion is saying is not just “99 or more” but also
“is in the range of 99 or more”. The “in the range of” is implied in
addition to the + as “or more”.

a 99+

It feels empty of the relationship even if 99+ has the range meaning.
Compare:

a in 99+

That feels clearer to me. Both concepts are now made explicit. The language
Pascal has ranges and a membership clause. ADA also embraced some of it. We
could imagine:

a in 99..
a in 99..123

The “in” part feels important to me.

Michael


On Thu, Apr 23, 2020 at 6:32 PM anon notmyfault64 
wrote:

> In this context, this number plus syntax short-circuit more than or equal,
> so
>
> a 99+
>
> is same as
>
> a >= 99
>
>
>
> On Thursday, April 23, 2020 at 11:43:32 PM UTC+7, Ian Lance Taylor wrote:
>>
>> On Thu, Apr 23, 2020 at 8:48 AM anon notmyfault64 
>> wrote:
>> >
>> > Many times outside programming we use "number plus" postfix syntax to
>> denote more than or equal, for example:
>> >
>> > a 99+
>> >
>> > But why isn't there such syntax above in all programming languages,
>> including Go? That is, why does following code not compile with invalid
>> syntax error?
>> >
>> > var r int = 18
>> >
>> > if r 13+ {
>> > fmt.Println("Hooray! We are teen! We can do anything!")
>> > } else {
>> > fmt.Println("Oh No! We are still child, so we need parental
>> control!")
>> > }
>>
>> I don't see the advantage over writing r >= 13.
>>
>> It's not useful for a programming language to have multiple ways of
>> writing the exact same thing.  Of course, any language does have
>> multiple ways of doing some things, but there is should always be a
>> reason for it.  I don't see a reason for this one.
>>
>> For what it's worth, I'm not familiar with the "a 99+" notation.  I
>> would not know what that meant without an explanation.
>>
>> Ian
>>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/77d05b4d-6743-48ed-affa-b6fb66d13500%40googlegroups.com
> 
> .
>
-- 

*Michael T. jonesmichael.jo...@gmail.com *

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALoEmQwHxsc_xQ%3DU%2BhWFx5JHqVZ_%2B2GkAveLBpE6BYenG8%2Brng%40mail.gmail.com.

[go-nuts] Re: Why does for-range behaves differently depend on the slice's struc size?

[Tamás Gulácsi]

2020. április 24., péntek 14:26:08 UTC+2 időpontban Yulrizka a következőt 
írta:
>
> Hello, 
>
>
> I was playing around with this code 
>
> main_var.go
> package main
>
> func main() {
> const size = 100
>
> slice := make([]SomeStruct, size)
> for _, s := range slice { // line 7
> _ = s
> }
>
> }
>
>
> type_small.go
> package main
>
> type SomeStruct struct {
> ID0 int64
> ID1 int64
> ID2 int64
> ID3 int64
> ID4 int64
> ID5 int64
> ID6 int64
> ID7 int64
> ID8 int64
> }
>
>
> I noted that if i added anoteher 64 bit int64 `ID9` (total of 10 * 8 byte 
> = 80 byte) integer to the struct, the for-loop becomes slower.
> And if I compare the assembly, it added instruction to copy the element
>
> // with 9 int64 (72 bytes)
> 0x001d 00029 (main_var.go:6)LEAQtype."".SomeStruct(SB), AX
> 0x0024 00036 (main_var.go:6)MOVQAX, (SP)
> 0x0028 00040 (main_var.go:6)MOVQ$100, 8(SP)
> 0x0031 00049 (main_var.go:6)MOVQ$100, 16(SP)
> 0x003a 00058 (main_var.go:6)CALLruntime.makeslice(SB)
> 0x003f 00063 (main_var.go:6)XORLAX, AX
> 0x0041 00065 (main_var.go:7)INCQAX
> 0x0044 00068 (main_var.go:7)CMPQAX, $100
> 0x004a 00074 (main_var.go:7)JLT65
> 0x004c 00076 (main_var.go:7)MOVQ32(SP), BP
> 0x0051 00081 (main_var.go:7)ADDQ$40, SP
> 0x0055 00085 (main_var.go:7)RET
> 0x0056 00086 (main_var.go:7)NOP
> 0x0056 00086 (main_var.go:3)CALLruntime.morestack_noctxt(SB)
> 0x005b 00091 (main_var.go:3)JMP0
>
> // with 10 int64 (80 bytes), it added DUFFCOPY instruction
> 0x001d 00029 (main_var.go:6)LEAQtype."".SomeStruct(SB), AX
> 0x0024 00036 (main_var.go:6)MOVQAX, (SP)
> 0x0028 00040 (main_var.go:6)MOVQ$100, 8(SP)
> 0x0031 00049 (main_var.go:6)MOVQ$100, 16(SP)
> 0x003a 00058 (main_var.go:6)CALLruntime.makeslice(SB)
> 0x003f 00063 (main_var.go:6)MOVQ24(SP), AX
> 0x0044 00068 (main_var.go:6)XORLCX, CX
> 0x0046 00070 (main_var.go:7)JMP76
> 0x0048 00072 (main_var.go:7)ADDQ$80, AX
> 0x004c 00076 (main_var.go:7)LEAQ""..autotmp_7+32(SP), DI
> 0x0051 00081 (main_var.go:7)MOVQAX, SI
> 0x0054 00084 (main_var.go:7)DUFFCOPY$826 # <-- copy the 
> element
> 0x0067 00103 (main_var.go:7)INCQCX
> 0x006a 00106 (main_var.go:7)CMPQCX, $100
> 0x0071 00113 (main_var.go:7)JLT72
> 0x0073 00115 (main_var.go:7)MOVQ112(SP), BP
> 0x0078 00120 (main_var.go:7)ADDQ$120, SP
> 0x007c 00124 (main_var.go:7)RET
> 0x007d 00125 (main_var.go:7)NOP
> 0x007d 00125 (main_var.go:3)CALLruntime.morestack_noctxt(SB)
> 0x0082 00130 (main_var.go:3)JMP0
>
>
> I am just curious to why the bahavior is different on larger struct (> 80 
> bytes) even though in both cases the element of the slice is not being use.
>
> Thank you
>

After grepping the sources for DUFFCOPY,  
./cmd/compile/internal/ssa/rewriteAMD64.go suggests that it is a DUFFCOPY 
before SSA rewrites it to something faster - and this is a size-depending 
operation.

But I may be totally wrong...

-- 
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/a5d6949c-2dbe-498e-b7b5-e12eb14ccf08%40googlegroups.com.

[go-nuts] Re: thread local storage of C library from go application

[Pavan]

Thanks Tamas for elaborating.
 So if i understand, the C library will see the calls as if application is 
single threaded, i mean a single goroutine/thread issues C calls.
ofcourse go library can manage to distribute to different 
gorotuines/threads based on the API type .  will give more thoughts on it,

Regards,



On Wednesday, April 22, 2020 at 3:27:06 PM UTC+5:30, Tamás Gulácsi wrote:
>
>
> 2020. április 22., szerda 10:04:37 UTC+2 időpontban Pavan a következőt 
> írta:
>>
>>
>> Hi, 
>> putting the lockosthread from library cant match with goroutines TLS and 
>> its complex  on handling goroutines exit and mapping all the GO api's  (C 
>> fns if any with them ) called by applications to same OS thread . 
>>
>> ofcourse applications cant call lockosthread too as they are not aware of 
>> the GO API internals  of c functions usage. 
>>
>>
> In your library, spawn a goroutine, which 
> 1. calls runtime.LockOSThread, 
> 2. and then listens to commands on a channel, 
> 3. calls the C library,
> 4. responds on a channel given beside the command
> in a loop.
>
> And hide all this, and create the API that translates direct calls to such 
> command sending on the command channel,
> waiting for the answer and returning it.
>
> The essence is that the C-calling goroutine must be on the same thread 
> where it has started.
> This is to allow the C library to work, which assumes a lot about its 
> calling environment when storing data in thread-local storage
>
>

-- 
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/974a91b7-da44-49c8-af4a-3c8b5147b25d%40googlegroups.com.

Re: [go-nuts] Re: Is the following funciton always safe to convert a string to a slice?

[T L]

Many thanks. This is quite informative.

On Wednesday, April 22, 2020 at 4:44:18 PM UTC-4, Ian Lance Taylor wrote:
>
> On Wed, Apr 22, 2020 at 7:08 AM T L > 
> wrote: 
> > 
> > I understand that, by the case 6 in the unsafe package docs, 
> > the second program should be safe with or without the runtime.KeepAlive 
> call. 
> > I just wonder how Go runtime achieves this goal. 
> > I have an impression that pointer assignments in Go by gc is atomically, 
> > but is this also true for uintptr value assignments? 
>
> Using the meaning of "atomic" from my previous message, then, yes, 
> both pointer assignments and uintptr assignments are done in a way 
> that can not be interrupted.  That more or less happens automatically, 
> as it's a single machine instruction either way.  And in fact it's the 
> same machine instruction, since pointers and uintptr are the same size 
> and use the same registers. 
>
> Ian 
>
>
> > On Wednesday, April 22, 2020 at 7:33:22 AM UTC-4, T L wrote: 
> >> 
> >> 
> >> 
> >> On Tuesday, April 21, 2020 at 8:13:17 PM UTC-4, Ian Lance Taylor wrote: 
> >>> 
> >>> On Tue, Apr 21, 2020 at 8:17 AM T L  wrote: 
> >>> > 
> >>> > And is the runtime.KeepAlive call in the following program essential 
> to keep the correctness? 
> >>> > 
> >>> > package main 
> >>> > 
> >>> > import ( 
> >>> > "fmt" 
> >>> > "unsafe" 
> >>> > "reflect" 
> >>> > "runtime" 
> >>> > ) 
> >>> > 
> >>> > func main() { 
> >>> > a := [6]byte{'G', 'o', 'o', 'g', 'l', 'e'} 
> >>> > bs := []byte("Golang") 
> >>> > hdr := (*reflect.SliceHeader)(unsafe.Pointer()) 
> >>> > hdr.Data = uintptr(unsafe.Pointer()) 
> >>> > 
> >>> > runtime.KeepAlive() // Is this line essential here? 
> >>> > 
> >>> > hdr.Len = 2 
> >>> > hdr.Cap = len(a) 
> >>> > fmt.Printf("%s\n", bs) // Go 
> >>> > bs = bs[:cap(bs)] 
> >>> > fmt.Printf("%s\n", bs) // Google 
> >>> > } 
> >>> 
> >>> I do not think the runtime.KeepAlive is required.  Setting the Data 
> >>> field using a *SliceHeader should keep the value alive. 
> >>> 
> >>> Ian 
> >> 
> >> 
> >> 
> >> Many thanks for the answers. 
> >> 
> >> I have another question, which doesn't matter with or without the 
> runtime.KeepAlive call. 
> >> We know that assignment in Go is not atomic. 
> >> Is it possible that when the assignment "hdr.Data = 
> uintptr(unsafe.Pointer())" is half done, 
> >> the stack is resized, so the address of a might be changed (assume a is 
> allocated on stack), 
> >> the hdr.Data will be assigned the old invalid value? 
> >> 
> > -- 
> > 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 golan...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/2b9b1bec-4176-421f-8820-a6ff2bf2ead2%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/1f4cb812-0301-4858-ba7d-669853d2e27c%40googlegroups.com.

[go-nuts] Why does for-range behaves differently depend on the slice's struc size?

[Yulrizka]

Hello, 


I was playing around with this code 

main_var.go
package main

func main() {
const size = 100

slice := make([]SomeStruct, size)
for _, s := range slice { // line 7
_ = s
}

}


type_small.go
package main

type SomeStruct struct {
ID0 int64
ID1 int64
ID2 int64
ID3 int64
ID4 int64
ID5 int64
ID6 int64
ID7 int64
ID8 int64
}


I noted that if i added anoteher 64 bit int64 `ID9` (total of 10 * 8 byte = 
80 byte) integer to the struct, the for-loop becomes slower.
And if I compare the assembly, it added instruction to copy the element

// with 9 int64 (72 bytes)
0x001d 00029 (main_var.go:6)LEAQtype."".SomeStruct(SB), AX
0x0024 00036 (main_var.go:6)MOVQAX, (SP)
0x0028 00040 (main_var.go:6)MOVQ$100, 8(SP)
0x0031 00049 (main_var.go:6)MOVQ$100, 16(SP)
0x003a 00058 (main_var.go:6)CALLruntime.makeslice(SB)
0x003f 00063 (main_var.go:6)XORLAX, AX
0x0041 00065 (main_var.go:7)INCQAX
0x0044 00068 (main_var.go:7)CMPQAX, $100
0x004a 00074 (main_var.go:7)JLT65
0x004c 00076 (main_var.go:7)MOVQ32(SP), BP
0x0051 00081 (main_var.go:7)ADDQ$40, SP
0x0055 00085 (main_var.go:7)RET
0x0056 00086 (main_var.go:7)NOP
0x0056 00086 (main_var.go:3)CALLruntime.morestack_noctxt(SB)
0x005b 00091 (main_var.go:3)JMP0

// with 10 int64 (80 bytes), it added DUFFCOPY instruction
0x001d 00029 (main_var.go:6)LEAQtype."".SomeStruct(SB), AX
0x0024 00036 (main_var.go:6)MOVQAX, (SP)
0x0028 00040 (main_var.go:6)MOVQ$100, 8(SP)
0x0031 00049 (main_var.go:6)MOVQ$100, 16(SP)
0x003a 00058 (main_var.go:6)CALLruntime.makeslice(SB)
0x003f 00063 (main_var.go:6)MOVQ24(SP), AX
0x0044 00068 (main_var.go:6)XORLCX, CX
0x0046 00070 (main_var.go:7)JMP76
0x0048 00072 (main_var.go:7)ADDQ$80, AX
0x004c 00076 (main_var.go:7)LEAQ""..autotmp_7+32(SP), DI
0x0051 00081 (main_var.go:7)MOVQAX, SI
0x0054 00084 (main_var.go:7)DUFFCOPY$826 # <-- copy the element
0x0067 00103 (main_var.go:7)INCQCX
0x006a 00106 (main_var.go:7)CMPQCX, $100
0x0071 00113 (main_var.go:7)JLT72
0x0073 00115 (main_var.go:7)MOVQ112(SP), BP
0x0078 00120 (main_var.go:7)ADDQ$120, SP
0x007c 00124 (main_var.go:7)RET
0x007d 00125 (main_var.go:7)NOP
0x007d 00125 (main_var.go:3)CALLruntime.morestack_noctxt(SB)
0x0082 00130 (main_var.go:3)JMP0


I am just curious to why the bahavior is different on larger struct (> 80 
bytes) even though in both cases the element of the slice is not being use.

Thank you

-- 
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/fdcd923e-7c21-4e50-ac51-725f5aa0666d%40googlegroups.com.

[go-nuts] http2 scatter/gather API

[bjboreham]

When looking at the performance of streaming gRPC, I found that a lot of 
garbage is created from
appending two slices before calling http2 Framer.WriteData().
(more detail: https://github.com/grpc/grpc-go/issues/3560)

So, I thought it would be nice if http2 offered a WriteData() that took 
multiple byte slices.
Has that been discussed already?


-- 
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/f393305b-a32f-4bfc-a768-88fc44d648bd%40googlegroups.com.

[go-nuts] terminating goruntime internal threads

[Pavan]

Hi, 
how do we terminate the go generated internal OS threads.  I am debugging 
an issue , where  RES(memory resdent size)  size of. a process increases as 
goroutines used increases. 
Iam trying to reduce the threads footprint contribution of process RES , 
hence.  terminate the additional threads once go routines are completed.  

Is there an explicit call, I can make to terminate these processes. 

For the OS threads because of C functions calls, I am doing LockOSThread 
and skipping unlock, so that they terminate as goroutine terminates. 

I see some discussion of this here: 
https://github.com/golang/go/issues/14592
but could not find if an explicit call was introduced for application to 
call terminate. 


Regards,

-- 
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/af9a3a75-c381-49c3-be6e-ce21e74a247c%40googlegroups.com.