[go-nuts] A Question about `unsafe.Slice`

Please take a look at the following code: ```go package main import ( "fmt" "runtime" "unsafe" ) func assert(b bool) { if b { } else { panic("unexpected") } } type Elementer interface { GetInt64Slice() []int64 GetByteSlice() []byte String() string }

Re: [go-nuts] A question about channel

On Tue, Sep 14, 2021 at 9:30 AM LinkinStar wrote: > > Hi golang-nuts, > When I read the source code about chan.go, I found some problems that were a > little difficult to understand. > > hchan has two function, full and empty. > > func full(c *hchan) bool { > // c.dataqsiz is immutable (never wri

[go-nuts] A question about channel

Hi golang-nuts, When I read the source code about chan.go, I found some problems that were a little difficult to understand. hchan has two function, full and empty. func full(c *hchan) bool { // c.dataqsiz is immutable (never written after the channel is created) // so it is safe to read at any

[go-nuts] A question about Type Sets

Hi golang-nuts, I am trying out the latest type parameter and type sets design. The purpose is to implement a Clamp function that works for numbers and vectors. The version for numbers is straightforward and easy: ```go // Number is a type set of numbers. type Number interface { ~int | ~int8 | ~

[go-nuts] A Question About Type Set and Parameter Design

Hi golang-nuts, I am trying out the latest type parameter, and type sets design. The purpose is to implement a Clamp function that works for numbers and vectors. The version for numbers is straightforward and easy: ```go // Number is a type set of numbers. type Number interface { ~int | ~int

[go-nuts] A question about metric `/sched/latencies:seconds` in go1.17's package runtime/metrics

Hi, I am reading the description of metric `/sched/latencies:seconds` in runtime/metrics: ``` /sched/latencies:seconds Distribution of the time goroutines have spent in the scheduler in a runnable state before actually running. ``` I wonder such records are from all the goroutines' `runn

[go-nuts] A question about go bug template

In the go bug template, go version is printed twice, the first time in the "go version" section and the second time in the "details" section as GOROOT/bin/go version. After https://golang.org/cl/288693 , these two entries should show the same version. In order for them to differ, one should do

Re: [go-nuts] A question about copying

Aha, I see. Thanks for explaining. br. Chr. lørdag den 25. juli 2020 kl. 10.56.35 UTC+2 skrev Jan Mercl: > On Sat, Jul 25, 2020 at 10:09 AM chri...@surlykke.dk > wrote: > > > Is this something I should have deduced from the language spec? > > https://golang.org/ref/spec#Address_operators > > ""

Re: [go-nuts] A question about copying

On Sat, Jul 25, 2020 at 10:09 AM chri...@surlykke.dk wrote: > Is this something I should have deduced from the language spec? https://golang.org/ref/spec#Address_operators For an operand x of type T, the address operation &x generates a pointer of type *T to x. The operand must be addressa

Re: [go-nuts] A question about copying

You are probably thinking about code like this: var f2 = *f1 Which will make a copy, although not because `f1` is dereferenced, but because `=` was called on a value. Dereferencing a pointer gives a reference to the same value, taking address of the same value will produce a pointer to the same

Re: [go-nuts] A question about copying

On Sat, 2020-07-25 at 01:09 -0700, chri...@surlykke.dk wrote: > &(*f1) > > would, first, create a copy of *f1, and then a pointer to that copy, > but evidently f2 becomes a pointer to the same struct as f1. Is this > something I should have deduced from the language spec? &(*p) says "give me the

[go-nuts] A question about copying

When running this program: package main import ( "fmt" ) type Foo struct { i int } func main() { var f1 = &Foo{i: 0} var f2 = &(*f1) f2.i = 1 fmt.Println(f1, f2) } it yields: &{1} &{1} (https://play.golang.org/p/qKtURokUCEW) I (naively) assumed that the expression &(*f1) would, first, c

Re: [go-nuts] A question !

Well, don’t benchmark it, bookmark it :) > On Jan 4, 2020, at 5:51 PM, robert engels wrote: > > Please everyone just benchmark this page > https://www.techempower.com/benchmarks/ > > > Rant ON... Python is not suitable for any high volume server appli

Re: [go-nuts] A question !

Please everyone just benchmark this page https://www.techempower.com/benchmarks/ Rant ON... Python is not suitable for any high volume server application. It is designed for simple scripting. Rant OFF. > On Jan 4, 2020, at 5:41 PM, Justin Israel wrote

[go-nuts] A question !

Hello Guyz , This is Hejaze from Egypt Currently i wok as a python django web developer I am new to Golang and i want to ask you guys with experience 1 - Is there really a big performance ( speed ) difference between using Python OR Golang in backend web development ? 2 - What is the fastest r

Re: [go-nuts] A question about performance when traverse the array with row-wise and column-wise

I think in my test code, what affect the performance maybe the cpu branches misses? The row num is bigger than the column num, so in column-wise traverse, the inner loop is easier to predict. perf result: row-wise 0.034014712741,811 branch-misses # 1.05% o

Re: [go-nuts] A question about performance when traverse the array with row-wise and column-wise

On my machine using an intel 9880H with a L2 Cache: Unified, 256 KiB, 4-way set associative, rows vs. columns performance is basically the same as long as the array size fits into the L2 cache. This seems to be the case for a rowSize = colSize = 180. For slightly higher values (190) the colum

[go-nuts] A question about performance when traverse the array with row-wise and column-wise

The test code is below: package main import ( "testing" ) const rowSize = 100 const colSize = 100 var array [rowSize][colSize]int func BenchmarkRow(b *testing.B) { b.ResetTimer() for i := 0; i < b.N; i++ { sum := 0 for r := 0; r < rowSize; r++ { for c := 0; c < colSize; c++ { sum += array[r

Re: [go-nuts] A question about go tool trace scheduler time

Also, based on the number of Go routine 4k, and the Go routine ID - you may be cycling through threads really rapidly, if the Go routines are using blocking calls that are spawning new threads - as these spin up you will increase the scheduler wait time. > On Jul 28, 2019, at 4:42 PM, robert en

Re: [go-nuts] A question about go tool trace scheduler time

goanalyzer might help you understand what is happening better. The schedule wait time looks high, but this time is dependent on the number of active (usually CPU bound) Go routines vs. GOMAXPROCS (which is usually limited by number of CPUs). > On Jul 27,

Re: [go-nuts] A question about A sync.Once implementation.

I'm quite sorry for that. This is my first time posting code here. Here's go playground link: https://play.golang.org/p/9xVjoD7rI0F. 在 2019年5月7日星期二 UTC+8下午10:08:39，Ian Lance Taylor写道： > > On Tue, May 7, 2019 at 5:55 AM > wrote: > > > > Hi, > > I did a quiz recently, but I'm having probl

Re: [go-nuts] A question about A sync.Once implementation.

On Tue, May 7, 2019 at 5:55 AM wrote: > > Hi, > I did a quiz recently, but I'm having problem with the answer. > Quiz: https://github.com/smallnest/go-concurrent-quiz#-quiz-4 When sending code, please just send plain text or a link to play.golang.org. Thanks. I can't actually re

[go-nuts] A question about A sync.Once implementation.

Hi, I did a quiz recently, but I'm having problem with the answer. Quiz: https://github.com/smallnest/go-concurrent-quiz#-quiz-4 package doublecheck import ( "sync" ) type Once struct { msync.Mutex done uint32 } func (o *Once) Do(f func()) {

Re: [go-nuts] a question about go

Because 3.0 == 3 and the documentation for the fmt package says the default verb (%v) for floats prints only so much digits as needed, which also implies training zeros will be dropped until explicitly asked for by a different formatting verb, like %f3.1, for example. On Thu, Dec 20, 2018, 18:29 J

[go-nuts] a question about go

This is the code I find when I read the a book about Golang. I have a question why the result is 1,2,3,4 instead of 1, 2, 3.0 and 4.0 when bx and by are float. Could anyone help me? Thanks a lot! [image: Screen Shot 2018-12-20 at 11.59.07 PM.png] -- You received this message because you are

[go-nuts] A question about the description of sync.Pool.Get

It emphasize "Callers should not assume any relation between values passed to Put and the values returned by Get." It is to allow the implementation to do as it wish - it is not a free list, but a GC-friendly hack that helps amortize allocation cost for unknown number of goroutines. -- You re

[go-nuts] A question about the description of sync.Pool.Get

Can anyone explain the meaning of " Get may choose to ignore the pool and treat it as empty." in https://golang.org/pkg/sync/#Pool.Get? > Get selects an arbitrary item from the Pool, removes it from the Pool, and returns it to the caller. Get may choose to ignore the pool and treat it as empty. Ca

Re: [go-nuts] A question about evaluation of channel’s send statement

yes, It is a data race. But the problem mentioned by op is not caused by data race. On Tuesday, September 12, 2017 at 3:59:32 AM UTC-4, Konstantin Khomoutov wrote: > > On Wed, Sep 06, 2017 at 04:26:09AM -0700, T L wrote: > > > > > It is just weird that the evaluation timing of *p is different to

Re: [go-nuts] A question about evaluation of channel’s send statement

On Wed, Sep 06, 2017 at 04:26:09AM -0700, T L wrote: > > > It is just weird that the evaluation timing of *p is different to other > > expressions, such as, *p+0, *p*1, func()int{return *p}m etc. > > > > The value depends on a data race so it's entirely undefined in all cases. > > That the actu

Re: [go-nuts] A question about evaluation of channel’s send statement

On Wednesday, September 6, 2017 at 7:38:04 AM UTC-4, T L wrote: > > > > On Wednesday, September 6, 2017 at 6:40:46 AM UTC-4, Jakob Borg wrote: >> >> On 6 Sep 2017, at 10:28, T L wrote: >> > It is just weird that the evaluation timing of *p is different to other >> expressions, such as, *p+0, *

Re: [go-nuts] A question about evaluation of channel’s send statement

On Wednesday, September 6, 2017 at 6:40:46 AM UTC-4, Jakob Borg wrote: > > On 6 Sep 2017, at 10:28, T L > wrote: > > It is just weird that the evaluation timing of *p is different to other > expressions, such as, *p+0, *p*1, func()int{return *p}m etc. > > The value depends on a data race so it

Re: [go-nuts] A question about evaluation of channel’s send statement

On Wednesday, September 6, 2017 at 6:40:46 AM UTC-4, Jakob Borg wrote: > > On 6 Sep 2017, at 10:28, T L > wrote: > > It is just weird that the evaluation timing of *p is different to other > expressions, such as, *p+0, *p*1, func()int{return *p}m etc. > > The value depends on a data race so it

Re: [go-nuts] A question about evaluation of channel’s send statement

On 6 Sep 2017, at 10:28, T L wrote: > It is just weird that the evaluation timing of *p is different to other > expressions, such as, *p+0, *p*1, func()int{return *p}m etc. The value depends on a data race so it's entirely undefined in all cases. That the actual outcome then depends on trivial

Re: [go-nuts] A question about evaluation of channel’s send statement

On Tuesday, September 5, 2017 at 11:04:52 PM UTC-4, Jesse McNelis wrote: > > On Wed, Sep 6, 2017 at 2:26 AM, T L > > wrote: > > > > I mean it can be viewed as a bug for inconsistency. > > But from the memory model view, it can also not be viewed as a bug. > > > > It's not a bug. The code is

Re: [go-nuts] A question about evaluation of channel’s send statement

On Wed, Sep 6, 2017 at 2:26 AM, T L wrote: > > I mean it can be viewed as a bug for inconsistency. > But from the memory model view, it can also not be viewed as a bug. > It's not a bug. The code is clearly expecting some ordering between internal operations within two goroutines, this is an inco

Re: [go-nuts] A question about evaluation of channel’s send statement

On Tuesday, September 5, 2017 at 12:20:02 PM UTC-4, T L wrote: > > IMO, I think this is a bug. > I mean it can be viewed as a bug for inconsistency. But from the memory model view, it can also not be viewed as a bug. > > On Tuesday, September 5, 2017 at 12:16:56 PM UTC-4, T L wrote: >> >> BTW

Re: [go-nuts] A question about evaluation of channel’s send statement

IMO, I think this is a bug. On Tuesday, September 5, 2017 at 12:16:56 PM UTC-4, T L wrote: > > BTW, the following one also prints 10. > > package main > > import ( > "fmt" > "time" > ) > > func main() { > var num = 10 > var p = &num > > c := make(chan int) > > go func() { >

Re: [go-nuts] A question about evaluation of channel’s send statement

BTW, the following one also prints 10. package main import ( "fmt" "time" ) func main() { var num = 10 var p = &num c := make(chan int) go func() { c <- *p * 1 // with this line we will get 11 from channel c //c <- num // with this line we will get 10 fr

Re: [go-nuts] A question about evaluation of channel’s send statement

The program is really racy, but the result is also really some counter-intuitive. The following program also print 10, which means evaluation of pointer dereference is some different to evaluation of other expressions in flow. package main import ( "fmt" "time" ) func main() { var

Re: [go-nuts] A question about evaluation of channel’s send statement

On Tue, Sep 5, 2017 at 10:34 AM, Marlon Che wrote: > Hi everyone! > Please help me figure out the two different results of following code: > > package main > > import ( > "fmt" > "time" > ) > > func main() { > var num = 10 > var p = &num > > c := make(chan int) > > go func(

[go-nuts] A question about evaluation of channel’s send statement

Hi everyone! Please help me figure out the two different results of following code: package main import ( "fmt" "time" ) func main() { var num = 10 var p = &num c := make(chan int) go func() { c <- *p // with this line we will get 11 from channel c //c <

Re: [go-nuts] A question about race conditions

Can you provide example code which demonstrates the problem? What you are describing is not expected. Reading and writing to channels simultaneously with the `<-` operator from multiple goroutines should not generate memory race conditions by themselves, but concurrency is complicated and it is st

[go-nuts] A question about race conditions

Hello All I have a question about the use of race condition detector. (compiling with -race options, to be precise). I have a program which has a channel (size 1024): one goroutine is reading and one is writing. When I compile using -race , the detector says there is a race condition on the

Re: [go-nuts] A question about reading of TCP sockets.

Hi I was under this impression, too I think for my purposes is Better to use a TLV based stream, also because I am familiar with TLVs. Which means, a naturally delimited syntax, as you said. Thanks for the clarification on tcp read behavior. Thank On 20 May 2017 17:39, "Jesper Louis Andersen" <

Re: [go-nuts] A question about reading of TCP sockets.

Hi, TCP is a stream-oriented protocol. When you send your 1516 bytes, the receiver may read anything from 0 to 1516 bytes when they execute the read. The reason is that the operating system kernels in both ends are free to "chop up" the stream at any point. Furthermore, transmission errors and ret

[go-nuts] A question about reading of TCP sockets.

Hello All first I apologize for my English, I'm not a native speaker. I have a question about how golang reads the sockets in tcp. Imagine I send , using a conn.Write(buffer), a buffer which has the (unpredictable) size from 80 Bytes to 1516. Now, if I do something like this (after creating "l

Re: [go-nuts] A question about the atomic operations in golang

Yes, the author of that post is also me : ) 在 2017年1月9日星期一 UTC+8下午6:30:59，Konstantin Khomoutov写道： > > On Sun, 8 Jan 2017 01:22:59 -0800 (PST) > 陈诚 > wrote: > > > Is the size of a pointer value 32 bits or 64 bits in golang when > > build with `GOARCH=amd64` option specified and running on 64-bit

Re: [go-nuts] A question about the atomic operations in golang

On Sun, 8 Jan 2017 01:22:59 -0800 (PST) 陈诚 wrote: > Is the size of a pointer value 32 bits or 64 bits in golang when > build with `GOARCH=amd64` option specified and running on 64-bit OS? [...] Isn't it http://stackoverflow.com/q/41531337/720999 ? -- You received this message because you are s

[go-nuts] A question about the atomic operations in golang

What you are talking about is called a torn write, which can occur if a value is written to memory but not aligned properly as the processor or memory subsystem must convert this write into two to correct for the miss alignment. Most processors that I know of, and all the ones that Go supports,

[go-nuts] A question about the atomic operations in golang

Is the size of a pointer value 32 bits or 64 bits in golang when build with `GOARCH=amd64` option specified and running on 64-bit OS? If it's 64-bit size, is a global pointer value 8-byte aligned in memory so that a read or write operation of that pointer value is carried out atomically? For exa

[go-nuts] A question, simple for go team

The string struct used internally is type stringStruct struct { str unsafe.Pointer len int } When following f function is called and s is cleared, how do go runtime knows the starting memory address of the old s.str is "a" instead of "c"? var s = "abcdefg"[2:5] // s.str should point a

Re: [go-nuts] A question about passing arguments to closure

In "go func(int) { fmt.Println(i)}(i)", 'i' is passed as an argument, but it is not used. 'fmt.Println(i)' uses the variable 'i' that is inherited from the parent function, because 'i' is not defined by the function func(int) as an argument and the next available 'i' is the one inherited from t

Re: [go-nuts] A question about passing arguments to closure

Hi Shawn, Thanks for yor answer! Another question, considering "go func(int) { fmt.Println(i)}(i)", the closure should accept an int argument but actually nothing is passed. Why does Go compiler allow this? Best Regards Nan Xiao On Mon, Jun 13, 2016 at 12:54 PM, Shawn Milochik wrote: > On Sun

Re: [go-nuts] A question about passing arguments to closure

On Sun, Jun 12, 2016 at 11:39 PM, Nan Xiao wrote: > Hi Shawn, > > Thanks for your reply! > > I can figure out the cause of what I have seen, but I want to know whether > there are detailed rules about processing parameters of closure. > > Best Regards > Nan Xiao > > Nan, If you pass in a value t

Re: [go-nuts] A question about passing arguments to closure

Hi Shawn, Thanks for your reply! I can figure out the cause of what I have seen, but I want to know whether there are detailed rules about processing parameters of closure. Best Regards Nan Xiao On Mon, Jun 13, 2016 at 11:33 AM, Shawn Milochik wrote: > The very first part of this will explain

Re: [go-nuts] A question about passing arguments to closure

The very first part of this will explain what you're seeing: https://github.com/golang/go/wiki/CommonMistakes -- 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 gol

[go-nuts] A question about passing arguments to closure

Hi all, I am a little confused about the parameters of Go closure. For example: package main > import ( > "fmt" > "time" > ) > func main() { > for i := 1; i <= 2; i++ { > go func(j int) { > fmt.Println(j, i) > }(i) > } > time.Sleep(time.Second) > } The running result is: > 1 3 > 2 3 Excep