Re: [go-nuts] How many times gc stw ?

[Ian Lance Taylor]

On Thu, Jun 20, 2019 at 7:22 PM Chou Yan  wrote:
>
> The describe 'release the physical memory' may not be rigorous. Because gc 
> remand the span,obj, or big obj to heap or central area, may not release the 
> physical memory.
> "When the next GC starts, it sweeps all not-yet-swept spans (if any)."
> maybe it is the sweeps termination phrase mean.
> BTW, I look the doc and look up three time of stw.
> sweep termination
>
> GC performs the mark phase. No objects may be
>
> //scanned until all Ps have enabled the write barrier, which is
> //accomplished using STW.
>
> mark termination phases.
> or "write barrier" accomplished during sweep termination?

The write barrier is enabled as sweep termination completes.

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/CAOyqgcV0vtmPZE%3D9jEUN6o9nfj%2BJ%2BoVEzc%3DphaUeXqjcoocZ2w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] How many times gc stw ?

[Ian Lance Taylor]

On Thu, Jun 20, 2019 at 7:00 PM Chou Yan  wrote:
>
> Sorry.
> Which I understand is that 'sweep termination = clean up = release the 
> physical memory'
> The long comment is helpful.
> I got
> 'b. Sweep any unswept spans. There will only be unswept spans if this GC 
> cycle was forced before the expected time.'
> Dose it means 'sweep = scan the root span', like java cms 'gc root scan'? not 
> the release the physical memory?

If I understand you correctly, the answer is yes.  Physical memory is
released by the scavenger.  On tip see runtime/mgcscavenge.go.

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/CAOyqgcXuZF8jFDrX4B8jK3dYWeWobR1JXyTC0Sf7sdMe4H9dAw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] How many times gc stw ?

[Chou Yan]

The describe 'release the physical memory' may not be rigorous. Because gc 
remand the span,obj, or big obj to heap or central area, may not release 
the physical memory.
"When the next GC starts, it sweeps all not-yet-swept spans (if any)."
maybe it is the sweeps termination phrase mean.
BTW, I look the doc and look up three time of stw.
sweep termination 

GC performs the mark phase. No objects may be

//scanned until all Ps have enabled the write barrier, which is
//accomplished using STW.

mark termination phases. 
or "write barrier" accomplished during sweep termination?  
在 2019年6月21日星期五 UTC+8上午8:54:31，Ian Lance Taylor写道：
>
> On Thu, Jun 20, 2019 at 9:56 AM Chou Yan  > wrote: 
> > 
> > I look up the doc for gctrace: 
> > https://godoc.org/runtime 
> > it show us: 
> > 
> > Currently, it is: 
> > gc # @#s #%: #+#+# ms clock, #+#/#/#+# ms cpu, #->#-># MB, # MB goal, # 
> P 
> > where the fields are as follows: 
> > gc #the GC number, incremented at each GC 
> > @#s time in seconds since program start 
> > #%  percentage of time spent in GC since program start 
> > #+...+# wall-clock/CPU times for the phases of the GC 
> > #->#-># MB  heap size at GC start, at GC end, and live heap 
> > # MB goal   goal heap size 
> > # P number of processors used 
> > The phases are stop-the-world (STW) sweep termination, concurrent 
> > mark and scan, and STW mark termination. The CPU times 
> > for mark/scan are broken down in to assist time (GC performed in 
> > line with allocation), background GC time, and idle GC time. 
> > If the line ends with "(forced)", this GC was forced by a 
> > runtime.GC() call. 
> > 
> > 
> > I am very confused. Will it be swt in the cleanup phase? 
>
> I'm sorry, I don't understand what you are asking.  What is the cleanup 
> phase? 
>
> > And how many times gc stw? mark start? concurrent mark? remark ? or 
> sweep ? 
>
> See the long comment near the top of runtime/mgc.go.  Currently each 
> cycle stops the world twice, very briefly, in the sweep termination 
> and mark termination phases. 
>
> 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/7b0bedb9-3450-4502-bfa3-c290be1b51f8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] How many times gc stw ?

[Chou Yan]

Sorry. 
Which I understand is that 'sweep termination = clean up = release the 
physical memory'
The long comment is helpful.
I got 
'b. Sweep any unswept spans. There will only be unswept spans if this GC 
cycle was forced before the expected time.'
Dose it means 'sweep = scan the root span', like java cms 'gc root scan'? 
not the release the physical memory?

在 2019年6月21日星期五 UTC+8上午8:54:31，Ian Lance Taylor写道：
>
> On Thu, Jun 20, 2019 at 9:56 AM Chou Yan  > wrote: 
> > 
> > I look up the doc for gctrace: 
> > https://godoc.org/runtime 
> > it show us: 
> > 
> > Currently, it is: 
> > gc # @#s #%: #+#+# ms clock, #+#/#/#+# ms cpu, #->#-># MB, # MB goal, # 
> P 
> > where the fields are as follows: 
> > gc #the GC number, incremented at each GC 
> > @#s time in seconds since program start 
> > #%  percentage of time spent in GC since program start 
> > #+...+# wall-clock/CPU times for the phases of the GC 
> > #->#-># MB  heap size at GC start, at GC end, and live heap 
> > # MB goal   goal heap size 
> > # P number of processors used 
> > The phases are stop-the-world (STW) sweep termination, concurrent 
> > mark and scan, and STW mark termination. The CPU times 
> > for mark/scan are broken down in to assist time (GC performed in 
> > line with allocation), background GC time, and idle GC time. 
> > If the line ends with "(forced)", this GC was forced by a 
> > runtime.GC() call. 
> > 
> > 
> > I am very confused. Will it be swt in the cleanup phase? 
>
> I'm sorry, I don't understand what you are asking.  What is the cleanup 
> phase? 
>
> > And how many times gc stw? mark start? concurrent mark? remark ? or 
> sweep ? 
>
> See the long comment near the top of runtime/mgc.go.  Currently each 
> cycle stops the world twice, very briefly, in the sweep termination 
> and mark termination phases. 
>
> 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/58a54b06-271c-4c39-a891-2ec157c42ee9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Writing my first Go module

[Scott Pakin]

I've written a package to which I'm about to make an incompatible API 
change.  I figured this would be a good opportunity to learn about Go 
modules.  I think I understand the basics, but there are a few details I'm 
confused about:

First, on the repository side, all I need to do is include go.mod and go.sum 
and tag the commit with v2.0.0, right?  I figure I should probably also 
give the last commit of the old API its own go.mod and go.sum files and tag 
that commit with v1.0.0.

Second, if another user does a non-versioned import "github.com/my/module", 
is it true that they'll get the last pre-2.0 version and if they want the 
new API they have to explicitly import "github.com/my/module/v2"?  Or is 
that the case only if the user's program is also set up for versioning 
(i.e., has go.mod and go.sum files) and that the default is to get the 
latest commit, whatever its version?

Thanks,
— 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/fbd50494-9484-467f-b235-45b66bb63b86%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] interface{private()}

[Ian Lance Taylor]

On Thu, Jun 20, 2019 at 5:49 PM Gert  wrote:
>
> Thanks, does the go standard library have a use case where a private() 
> function in a interface is needed? Looking for more examples to understand 
> the benefit to do so.

Yes, in the go/ast package (and possibly elsewhere, but that's the
example that comes to mind).

Ian


> On Friday, June 21, 2019 at 2:36:01 AM UTC+2, Ian Lance Taylor wrote:
>>
>> On Thu, Jun 20, 2019 at 5:25 PM Gert  wrote:
>> >
>> > Trying to get my mind around why the private() function is necessary here. 
>> > I fail to understand the comment provided
>> >
>> > type Geometry interface {
>> >   GeoJSONType() string
>> >   Dimensions() int // e.g. 0d, 1d, 2d
>> >   Bound() Bound
>> >
>> >   // requiring because sub package type switch over all possible types.
>> >   private()
>> > }
>> >
>> > https://github.com/paulmach/orb/blob/master/geometry.go#L10
>>
>> Some packages use an unexported method like this to ensure that no
>> type defined outside of the package can implement the interface.
>>
>> 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/d5e8602c-7fdc-477e-806e-7e675bd5a2d3%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/CAOyqgcVoA0z2yv_d5nOFbqH6%2B_XhQFDfP896U3R0-g_MfXh%2BBQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] How many times gc stw ?

[Ian Lance Taylor]

On Thu, Jun 20, 2019 at 9:56 AM Chou Yan  wrote:
>
> I look up the doc for gctrace:
> https://godoc.org/runtime
> it show us:
>
> Currently, it is:
> gc # @#s #%: #+#+# ms clock, #+#/#/#+# ms cpu, #->#-># MB, # MB goal, # P
> where the fields are as follows:
> gc #the GC number, incremented at each GC
> @#s time in seconds since program start
> #%  percentage of time spent in GC since program start
> #+...+# wall-clock/CPU times for the phases of the GC
> #->#-># MB  heap size at GC start, at GC end, and live heap
> # MB goal   goal heap size
> # P number of processors used
> The phases are stop-the-world (STW) sweep termination, concurrent
> mark and scan, and STW mark termination. The CPU times
> for mark/scan are broken down in to assist time (GC performed in
> line with allocation), background GC time, and idle GC time.
> If the line ends with "(forced)", this GC was forced by a
> runtime.GC() call.
>
>
> I am very confused. Will it be swt in the cleanup phase?

I'm sorry, I don't understand what you are asking.  What is the cleanup phase?

> And how many times gc stw? mark start? concurrent mark? remark ? or sweep ?

See the long comment near the top of runtime/mgc.go.  Currently each
cycle stops the world twice, very briefly, in the sweep termination
and mark termination phases.

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/CAOyqgcW5ho6XOnUhaLBPXLrcqNN3h8sUtqTpz2BKRgcQtxNLug%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] interface{private()}

[Gert]

Thanks, does the go standard library have a use case where a private() 
function in a interface is needed? Looking for more examples to understand 
the benefit to do so.

On Friday, June 21, 2019 at 2:36:01 AM UTC+2, Ian Lance Taylor wrote:
>
> On Thu, Jun 20, 2019 at 5:25 PM Gert > 
> wrote: 
> > 
> > Trying to get my mind around why the private() function is necessary 
> here. I fail to understand the comment provided 
> > 
> > type Geometry interface { 
> >   GeoJSONType() string 
> >   Dimensions() int // e.g. 0d, 1d, 2d 
> >   Bound() Bound 
> > 
> >   // requiring because sub package type switch over all possible types. 
> >   private() 
> > } 
> > 
> > https://github.com/paulmach/orb/blob/master/geometry.go#L10 
>
> Some packages use an unexported method like this to ensure that no 
> type defined outside of the package can implement the interface. 
>
> 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/d5e8602c-7fdc-477e-806e-7e675bd5a2d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] interface{private()}

[Ian Lance Taylor]

On Thu, Jun 20, 2019 at 5:25 PM Gert  wrote:
>
> Trying to get my mind around why the private() function is necessary here. I 
> fail to understand the comment provided
>
> type Geometry interface {
>   GeoJSONType() string
>   Dimensions() int // e.g. 0d, 1d, 2d
>   Bound() Bound
>
>   // requiring because sub package type switch over all possible types.
>   private()
> }
>
> https://github.com/paulmach/orb/blob/master/geometry.go#L10

Some packages use an unexported method like this to ensure that no
type defined outside of the package can implement the interface.

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/CAOyqgcWOCJTZHEFPRRyRXW%3DxXq4QgnOO26aSieF25NZZkibsrQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] interface{private()}

[Gert]

Trying to get my mind around why the private() function is necessary here. 
I fail to understand the comment provided

type Geometry interface {
  GeoJSONType() string
  Dimensions() int // e.g. 0d, 1d, 2d
  Bound() Bound

  // requiring because sub package type switch over all possible types.
  private()
}

https://github.com/paulmach/orb/blob/master/geometry.go#L10

-- 
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/32e99338-dd59-4c34-8d0a-1d892a8a0655%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] The Seven Finest Go Books (to popularize and 'socialize' Go).

[Michael Jones]

There is a marvelous book that is about Go in a magical way...it explains
and teaches Go’s personality and attitude...from before Go was born. Read
Rob Pike and Brian Kernighan’s “The Practice of Programming.” After reading
it carefully you will understand Go in a deeper way than would otherwise be
possible. If you have a detective-like personally, study the author’s
credits for who advised them. You’ll think it was the “most frequent poster
ranking” for this mailing list... even though this all happened beforehand.

You’ll also become a better programmer. Truly.

On Thu, Jun 20, 2019 at 9:55 AM Aman Alam  wrote:

> Hi Rog,
>
> Are there any plans to make this book available for Kindle, or in PDF,
> please?
>
> Regards,
> Aman
>
> On Friday, February 22, 2019 at 4:29:29 AM UTC-5, rog wrote:
>>
>> You might want to take a look at Manning's "Get Programming With Go" too;
>> it's aimed mostly at more inexperienced programmers.
>>
>> https://www.amazon.com/Get-Programming-Go-Nathan-Youngman/dp/1617293091
>>
>> (disclosure: I'm one of the authors :])
>>
>>
>> On Thu, 21 Feb 2019 at 23:02, Akram Ahmad  wrote:
>>
>>>
>>>- The amazing language that golang surely is, and how refreshingly
>>>(and elegantly) simple a language golang is—take this from someone coming
>>>from extensive experience in Java and Scala, two language which
>>>well-deservedly have a lot going for them—I think we need to do
>>>*more* to popularize (and 'socialize') the promise of golang to the
>>>larger community of programmers.
>>>- To that end, I put together and recently posted a (fairly)
>>>detailed blog post: *Best Go Programming Books (2019)
>>>
>>> *
>>>.
>>>- Earlier posts (at least on golang) include the following two: *The
>>>Go Programming Language
>>>
>>> *
>>>and *Further Adventures In Go Land
>>>
>>> *
>>>.
>>>
>>> Go golang!
>>>
>>> Warm Regards to fellow gophers, hibernating or otherwise :)
>>>
>>>  ~Akram 
>>>
>>> --
>>> 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.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> 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/b8afaf18-d05d-4b5d-8ca7-306a41f76555%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 

*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/CALoEmQyDBe5JSjXV4U%3DUYpKSG_NEm0sKb%3DdBaiU3OH%3D609BOZA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] [Urgency] Error ctim value get from file.Stat().Sys().(*syscall.Stat_t)

[David Finkel]

On Thu, Jun 20, 2019 at 12:55 PM GoFreshMan <1on1y4u1...@gmail.com> wrote:

> *linux version: 5.1.9-300.fc30.x86_64*
> *linux dist: fedora 30*
> *go version: go1.12.5 linux/amd64*
>
>
> [ ~/Rhizobium]$ stat README.md
>  文件：README.md
>  大小：461块：8  IO 块：4096   普通文件
> 设备：805h/2053d  Inode：4199368 硬链接：1
> 权限：(0664/-rw-rw-r--)  Uid：( 1000/ dba)   Gid：( 1000/ dba)
> 环境：unconfined_u:object_r:user_home_t:s0
> 最近访问：2019-06-17 16:39:21.0 +0800 (last access)
> 最近更改：2019-06-18 10:40:27.0 +0800 (last change)
> 最近改动：2019-06-18 14:05:06.950815138 +0800 (last modified)
> 创建时间：2019-06-17 16:39:21.343782864 +0800 (create time)
>
>
>
>
> In my go program:
> package common
>
> import (
> "fmt"
> "os"
> "os/user"
> "syscall"
> "testing"
> "time"
> )
>
> func TestGetFileState(t *testing.T) {
> f, _ := os.Stat("/home/dba/Rhizobium/README.md")
> x := GetFileState1(f)
> fmt.Printf("%+v\n", f)
> fmt.Printf("%+v", x)
> }
>
> func GetFileState1(info os.FileInfo) FileStat1 {
> stat := info.Sys().(*syscall.Stat_t)
> fileState := FileStat1{
> Inode:   uint64(stat.Ino),
> Device:  uint64(stat.Dev),
> Name:info.Name(),
> Size:info.Size(),
> Mode:info.Mode(),
> CrtTime: time.Unix(int64(stat.Ctim.Sec), int64(stat.Ctim.Nsec)),
> ModTime: time.Unix(stat.Mtim.Sec, stat.Mtim.Nsec),
> AcsTime: time.Unix(stat.Atim.Sec, stat.Atim.Nsec),
> isDir:   info.IsDir(),
> }
> groupPointer, _ := user.LookupGroupId(fmt.Sprintf("%d", stat.Gid))
> fileState.userGroup = *groupPointer
>
> userPointer, _ := user.LookupId(fmt.Sprintf("%d", stat.Uid))
> fileState.user = *userPointer
> return fileState
> }
>
> type FileStat1 struct {
> Inode uint64
> Deviceuint64
> Name  string
> Size  int64 // bytes
> Mode  os.FileMode
> CrtTime   time.Time // 创建时间
> AcsTime   time.Time // 上次读取时间
> ModTime   time.Time // 上次修改时间
> isDir bool
> user  user.User
> userGroup user.Group
> }
>
> output:
>
> === RUN   TestGetFileState
> &{name:README.md size:461 mode:436 modTime:{wall:0 ext:63696422427
> loc:0x638c00} sys:{Dev:2053 Ino:4199368 Nlink:1 Mode:33204 Uid:1000
> Gid:1000 X__pad0:0 Rdev:0 Size:461 Blksize:4096 Blocks:8 Atim:{
> *Sec:1560760761* Nsec:0} Mtim:{Sec:1560825627 Nsec:0} Ctim:{Sec:
> *1560837906* Nsec:950815138} X__unused:[0 0 0]}}
> {Inode:4199368 Device:2053 Name:README.md Size:461 Mode:-rw-rw-r-- 
> CrtTime:*2019-06-18
> 14:05:06.950815138 +0800 CST* AcsTime:2019-06-17 16:39:21 +0800 CST
> ModTime:2019-06-18 10:40:27 +0800 CST isDir:false user:{Uid:1000 Gid:1000
> Username:dba Name:dba HomeDir:/home/dba} userGroup:{Gid:1000 Name:dba}}---
> PASS: TestGetFileState (0.00s)
> PASS
> ok  command-line-arguments 0.002s
>
>
> *Question:*
>
> why  file.Stat().Sys().(*syscall.Stat_t) get file create time is :
>
>  Ctim:{Sec:*1560837906* Nsec:950815138} === *2019-06-18
> 14:05:06.950815138 +0800 CST*
>
> access time is
>
> {*Sec:1560760761* Nsec:0}  2019-06-17 16:39:21 +0800
>
> It seems the ctim and atime just on the contray
>

We'd have to know more about the history of that particular file on your
system in order to provide more detailed information, but a couple things
to note that probably help explaining your confusion:

   - ctime is not the create time, it's the inode change time, so it gets
   updated whenever you change permissions, update the link-count (via a
   rename or  hardlink), or file-size change (among other things)
   - atime may not be reliable. E.G. filesystems mounted with the "noatime"
   option won't ever generate a write to the inode on its own to update the
   atime of a file; and "relatime" will limit how often it updates the atime
   timestamp.



>
> --
> 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/298e7dc4-1817-4933-a7d1-e9be00e9fa13%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CANrC0BgO_PTpjN3iq7NrUjE1B9JNimVS37H2khr0yiZ8JFeDhw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Could the go Tour be clearer on WHY recent make := zeroes

[Kevin Chadwick]

On 6/20/19 8:30 PM, fge...@gmail.com wrote:
> I'm not sure what you are asking for, but 
> the spec on initialization is quite clear:
> https://golang.org/ref/spec#The_zero_value
> 
> I'm curious which detailed literature are you referring to?

I was prompted by atleast a couple of books but also the spec.

Indeed the spec is clearer than I realised, had I clicked through on the link
you sent "initial values", here.

https://golang.org/ref/spec#Allocation

Perhaps the tour could link to that section of the spec?

https://tour.golang.org/moretypes/13

"allocates a zeroed array" -> "https://golang.org/ref/spec#The_zero_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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/982d264d-0e52-ad9e-775b-55172f06d29d%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Could the go Tour be clearer on WHY recent make := zeroes

[fgergo]

On Thu, Jun 20, 2019, 18:56 Kevin Chadwick  wrote:

> Hi
>
> "https://tour.golang.org/moretypes/13;
>
> "The make function allocates a zeroed array and returns a slice that
> refers to
> that array."
>
> Yet more detailed literature states that make does not zero whilst new
> does.
>
> I gather this is because the shorthand used in the tour, instantiates new
> in the
> background and wants to be as simple as possible for new users?
>
> I am not sure if that is actually most helpful. To avoid confusion, should
> it be
> something like:
>
> The shorthand make := syntax allocates a zeroed array (akin to
> automatically
> invoking new) and returns a slice that refers to that array?
>
> Regards, Kc
>
> --
> 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/e045f1c3-782f-f733-73a0-16eccf908ef4%40gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

I'm not sure what you are asking for, but
the spec on initialization is quite clear:
https://golang.org/ref/spec#The_zero_value

I'm curious which detailed literature are you referring to?

>

-- 
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/CA%2Bctqrr%3D5ThmWXBMTiprWpUwA9Rjs8SV%2BT_U83OYkQmPtBnj%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: godoc memory leak

[Tom Mitchell]

Thanks!

On Thu, Jun 20, 2019 at 11:23 AM Christopher Dang <
christopher.d...@wework.com> wrote:

> When I ran the godoc service in a docker image with less memory (6 GiB)
> the behavior was the same. For both a 8 GiB and 6 GiB machine, the godoc
> process continue to consume memory until it surpasses the memory on the
> machine and crashes. After the crash, the other processes on my machine
> continue to work and the memory is freed back entirely to the machine.
>
> On Thu, Jun 20, 2019 at 11:10 AM Tom Mitchell  wrote:
>
>>
>> On Mon, Jun 17, 2019 at 9:40 PM Agniva De Sarker <
>> agniva.quicksil...@gmail.com> wrote:
>>
>>> Couple of questions:
>>>
>>> 1. What version of godoc and Go are you using ? What is your go env ?
>>>
 One other question ...
>> If the OS supports limits does godoc fail nicely with smaller limits.
>> I am reminded of student code that would malloc(to-infinity-and-beyond)
>> because
>> student accounts had user limits and often began with a malloc() loop to
>> get
>> the largest amount possible to ease programming and speed things up.
>>
>>
>>
>> --
>>T o mM i t c h e l l
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/golang-nuts/nU706aM7QpM/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/CAAMy4UT4EUDviAgcw0is2fsXzUfp1Xvjc5cPW-_UThkxivdEDg%40mail.gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
   T o mM i t c h e l l

-- 
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/CAAMy4UR8%2B-1NJ9kyaHegGgN_%2Bg1JW8B-cswgae1aBB%2BpZwz-iQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: godoc memory leak

['Christopher Dang' via golang-nuts]

When I ran the godoc service in a docker image with less memory (6 GiB) the
behavior was the same. For both a 8 GiB and 6 GiB machine, the godoc
process continue to consume memory until it surpasses the memory on the
machine and crashes. After the crash, the other processes on my machine
continue to work and the memory is freed back entirely to the machine.

On Thu, Jun 20, 2019 at 11:10 AM Tom Mitchell  wrote:

>
> On Mon, Jun 17, 2019 at 9:40 PM Agniva De Sarker <
> agniva.quicksil...@gmail.com> wrote:
>
>> Couple of questions:
>>
>> 1. What version of godoc and Go are you using ? What is your go env ?
>>
>>> One other question ...
> If the OS supports limits does godoc fail nicely with smaller limits.
> I am reminded of student code that would malloc(to-infinity-and-beyond)
> because
> student accounts had user limits and often began with a malloc() loop to
> get
> the largest amount possible to ease programming and speed things up.
>
>
>
> --
>T o mM i t c h e l l
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/nU706aM7QpM/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CAAMy4UT4EUDviAgcw0is2fsXzUfp1Xvjc5cPW-_UThkxivdEDg%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAM8TFU7ROZ8sV2-9OcM0jM%3DYV6DawYN4A3ahj6NhxEErvxKfWg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: godoc memory leak

[Tom Mitchell]

On Mon, Jun 17, 2019 at 9:40 PM Agniva De Sarker <
agniva.quicksil...@gmail.com> wrote:

> Couple of questions:
>
> 1. What version of godoc and Go are you using ? What is your go env ?
>
>> One other question ...
If the OS supports limits does godoc fail nicely with smaller limits.
I am reminded of student code that would malloc(to-infinity-and-beyond)
because
student accounts had user limits and often began with a malloc() loop to
get
the largest amount possible to ease programming and speed things up.



-- 
   T o mM i t c h e l l

-- 
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/CAAMy4UT4EUDviAgcw0is2fsXzUfp1Xvjc5cPW-_UThkxivdEDg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] How many times gc stw ?

[Chou Yan]

I look up the doc for gctrace:
https://godoc.org/runtime
it show us:

Currently, it is:
gc # @#s #%: #+#+# ms clock, #+#/#/#+# ms cpu, #->#-># MB, # MB goal, # 
P
where the fields are as follows:
gc #the GC number, incremented at each GC
@#s time in seconds since program start
#%  percentage of time spent in GC since program start
#+...+# wall-clock/CPU times for the phases of the GC
#->#-># MB  heap size at GC start, at GC end, and live heap
# MB goal   goal heap size
# P number of processors used
The phases are stop-the-world (STW) sweep termination, concurrent
mark and scan, and STW mark termination. The CPU times
for mark/scan are broken down in to assist time (GC performed in
line with allocation), background GC time, and idle GC time.
If the line ends with "(forced)", this GC was forced by a
runtime.GC() call.


I am very confused. Will it be swt in the cleanup phase?

And how many times gc stw? mark start? concurrent mark? remark ? or sweep ?

-- 
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/0b509e5d-fe61-478b-9b88-f21a29d1f9cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Correct way to turn an image.Image into a *image.Paletted, for making gifs

[shubhamsharma1172]

Just use 

myPalette := append(palette.WebSafe, image.Transparent)


You can't add transparent color to plan9 palette since it's already full. 
Better to use WebSafe!


On Friday, 4 December 2015 14:05:56 UTC+5:30, Brian Picciano wrote:
>
> Ah, good call. So I've replaced the encode/decode nonsense with that and 
> things still work. Except transparency still isn't working :(
>
> Here is the function in question, the ctx simply holds onto a bunch of the 
> values, like the final gif.GIF being created and such:
>
> func (c *ctx) addFrame(img image.Image) error { 
> opts := gif.Options{ 
> NumColors: 256, 
> Drawer:draw.FloydSteinberg, 
> } 
> b := img.Bounds() 
>  
> // More or less taken from the image/gif package 
> pimg := image.NewPaletted(b, palette.Plan9[:opts.NumColors]) 
> if opts.Quantizer != nil { 
> pimg.Palette = opts.Quantizer.Quantize(make(color.Palette, 
> 0, opts.NumColors), img) 
> } 
> opts.Drawer.Draw(pimg, b, img, image.ZP) 
>  
> spf := 1 / float64(c.fps) 
>  
> c.g.Image = append(c.g.Image, pimg) 
> c.g.Delay = append(c.g.Delay, int(spf*100)) 
> return nil 
> }
>
>
>
> On Friday, December 4, 2015 at 1:19:35 AM UTC-7, Caleb Spare wrote:
>>
>> I'm not sure about the transparency thing. 
>>
>> In order to transform your image.Images into *image.Paletted, you can 
>> do what the gif encoder does. The code is very short: 
>>
>> https://github.com/golang/go/blob/master/src/image/gif/writer.go#L358-L366 
>>
>> (Basically, check if it's already an *image.Palleted; if not, use a 
>> quantizer to re-render it as a paletted image.) 
>>
>> -Caleb 
>>
>> On Thu, Dec 3, 2015 at 11:33 PM, Brian Picciano 
>>  wrote: 
>> > Hi there! I'm currently attempting to make a gif out of a series of 
>> > image.Image instances (each the same dimensions). I see that to build 
>> the 
>> > gif.GIF struct I need to somehow turn my image.Images into 
>> *image.Paletted, 
>> > but after browsing the various image apis I still don't see an obvious 
>> way 
>> > to do that. Currently I'm using gif.Encode to encode a single frame 
>> into a 
>> > buffer, then gif.DecodeAll to decode it back out into its own gif.GIF, 
>> and 
>> > then append that to my actual gif. This is super ugly and feels very 
>> wrong, 
>> > and it also seems to break transparency. Any help would be appreciated, 
>> > thanks! 
>> > 
>> > -- 
>> > 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. 
>> > For more options, visit https://groups.google.com/d/optout. 
>>
>

-- 
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/9751ae4c-6853-4c32-986e-3466a038e6af%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Could the go Tour be clearer on WHY recent make := zeroes

[Kevin Chadwick]

Hi

"https://tour.golang.org/moretypes/13;

"The make function allocates a zeroed array and returns a slice that refers to
that array."

Yet more detailed literature states that make does not zero whilst new does.

I gather this is because the shorthand used in the tour, instantiates new in the
background and wants to be as simple as possible for new users?

I am not sure if that is actually most helpful. To avoid confusion, should it be
something like:

The shorthand make := syntax allocates a zeroed array (akin to automatically
invoking new) and returns a slice that refers to that array?

Regards, Kc

-- 
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/e045f1c3-782f-f733-73a0-16eccf908ef4%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] [Urgency] Error ctim value get from file.Stat().Sys().(*syscall.Stat_t)

[GoFreshMan]

*linux version: 5.1.9-300.fc30.x86_64*
*linux dist: fedora 30*
*go version: go1.12.5 linux/amd64*


[ ~/Rhizobium]$ stat README.md
 文件：README.md
 大小：461块：8  IO 块：4096   普通文件
设备：805h/2053d  Inode：4199368 硬链接：1
权限：(0664/-rw-rw-r--)  Uid：( 1000/ dba)   Gid：( 1000/ dba)
环境：unconfined_u:object_r:user_home_t:s0
最近访问：2019-06-17 16:39:21.0 +0800 (last access)
最近更改：2019-06-18 10:40:27.0 +0800 (last change)
最近改动：2019-06-18 14:05:06.950815138 +0800 (last modified)
创建时间：2019-06-17 16:39:21.343782864 +0800 (create time)




In my go program:
package common

import (
"fmt"
"os"
"os/user"
"syscall"
"testing"
"time"
)

func TestGetFileState(t *testing.T) {
f, _ := os.Stat("/home/dba/Rhizobium/README.md")
x := GetFileState1(f)
fmt.Printf("%+v\n", f)
fmt.Printf("%+v", x)
}

func GetFileState1(info os.FileInfo) FileStat1 {
stat := info.Sys().(*syscall.Stat_t)
fileState := FileStat1{
Inode:   uint64(stat.Ino),
Device:  uint64(stat.Dev),
Name:info.Name(),
Size:info.Size(),
Mode:info.Mode(),
CrtTime: time.Unix(int64(stat.Ctim.Sec), int64(stat.Ctim.Nsec)),
ModTime: time.Unix(stat.Mtim.Sec, stat.Mtim.Nsec),
AcsTime: time.Unix(stat.Atim.Sec, stat.Atim.Nsec),
isDir:   info.IsDir(),
}
groupPointer, _ := user.LookupGroupId(fmt.Sprintf("%d", stat.Gid))
fileState.userGroup = *groupPointer

userPointer, _ := user.LookupId(fmt.Sprintf("%d", stat.Uid))
fileState.user = *userPointer
return fileState
}

type FileStat1 struct {
Inode uint64
Deviceuint64
Name  string
Size  int64 // bytes
Mode  os.FileMode
CrtTime   time.Time // 创建时间
AcsTime   time.Time // 上次读取时间
ModTime   time.Time // 上次修改时间
isDir bool
user  user.User
userGroup user.Group
}

output:

=== RUN   TestGetFileState
&{name:README.md size:461 mode:436 modTime:{wall:0 ext:63696422427 
loc:0x638c00} sys:{Dev:2053 Ino:4199368 Nlink:1 Mode:33204 Uid:1000 
Gid:1000 X__pad0:0 Rdev:0 Size:461 Blksize:4096 Blocks:8 Atim:{
*Sec:1560760761* Nsec:0} Mtim:{Sec:1560825627 Nsec:0} Ctim:{Sec:*1560837906* 
Nsec:950815138} X__unused:[0 0 0]}}
{Inode:4199368 Device:2053 Name:README.md Size:461 Mode:-rw-rw-r-- 
CrtTime:*2019-06-18 
14:05:06.950815138 +0800 CST* AcsTime:2019-06-17 16:39:21 +0800 CST 
ModTime:2019-06-18 10:40:27 +0800 CST isDir:false user:{Uid:1000 Gid:1000 
Username:dba Name:dba HomeDir:/home/dba} userGroup:{Gid:1000 Name:dba}}--- 
PASS: TestGetFileState (0.00s)
PASS
ok  command-line-arguments 0.002s


*Question:*

why  file.Stat().Sys().(*syscall.Stat_t) get file create time is :

 Ctim:{Sec:*1560837906* Nsec:950815138} === *2019-06-18 14:05:06.950815138 
+0800 CST*

access time is 

{*Sec:1560760761* Nsec:0}  2019-06-17 16:39:21 +0800

It seems the ctim and atime just on the contray


-- 
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/298e7dc4-1817-4933-a7d1-e9be00e9fa13%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


utils_linux_test.go
Description: Binary data

Re: [go-nuts] The Seven Finest Go Books (to popularize and 'socialize' Go).

[Aman Alam]

Hi Rog,

Are there any plans to make this book available for Kindle, or in PDF, 
please?

Regards,
Aman

On Friday, February 22, 2019 at 4:29:29 AM UTC-5, rog wrote:
>
> You might want to take a look at Manning's "Get Programming With Go" too; 
> it's aimed mostly at more inexperienced programmers.
>
> https://www.amazon.com/Get-Programming-Go-Nathan-Youngman/dp/1617293091
>
> (disclosure: I'm one of the authors :])
>
>
> On Thu, 21 Feb 2019 at 23:02, Akram Ahmad > 
> wrote:
>
>>
>>- The amazing language that golang surely is, and how refreshingly 
>>(and elegantly) simple a language golang is—take this from someone coming 
>>from extensive experience in Java and Scala, two language which 
>>well-deservedly have a lot going for them—I think we need to do *more* 
>>to popularize (and 'socialize') the promise of golang to the larger 
>>community of programmers. 
>>- To that end, I put together and recently posted a (fairly) detailed 
>>blog post: *Best Go Programming Books (2019) 
>>
>> *
>>.
>>- Earlier posts (at least on golang) include the following two: *The 
>>Go Programming Language 
>>
>> *
>>  
>>and *Further Adventures In Go Land 
>>
>> *
>>.
>>
>> Go golang!
>>
>> Warm Regards to fellow gophers, hibernating or otherwise :)
>>
>>  ~Akram 
>>
>> -- 
>> 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 .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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/b8afaf18-d05d-4b5d-8ca7-306a41f76555%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: is there a goroutine scope global veriable ?

[Robert Engels]

Yes, Windows 3.1 is new again... A primary benefit for Go - lightweight parallelism and concurrency of procedural functions - is thrown out the "window" with reactive style programming. No need to use reactive if using Go properly.-Original Message-
From: Henrik Johansson 
Sent: Jun 20, 2019 2:46 AM
To: Michael Jones 
Cc: Robert Engels , golang-nuts , jake6...@gmail.com
Subject: Re: [go-nuts] Re: is there a goroutine scope global veriable ?

On a practical note I think thread local storage is more or less discouraged in for example Java as wellbecause it makes all the new shine "reactive" tools break since they make no guarantees as to which thread you are running on.That may or may not be relevant to your case but to say that it's standard practice is probably not true any more.On Wed, Jun 19, 2019 at 8:49 PM Michael Jones  wrote:For the OP:A thought to share on the general topic: Go is pioneering a sufficiently different model of concurrent computation that it may not make much sense to ask for or seek equivalencies with classic thread/process models. This says nothing against the standard model, nor against the “missing” services; it is a note to encourage design in Go along with coding in Go, instead of design in C/C++/Java/POSIX/... and a best-effort realization in Go. By way of analogy, I’ve long been involved in boat design and construction. We always use a pair Furuno or Simrad RADAR antennas, one of long range and one short, to optimize object detection/clutter rejection and as a redundancy safety factor. However, when sailing on a HobeeCat, i’ve never looked for nor missed the Radar or any other instruments of navigation. A HobieCat is just such a different idea of sailing that *all* the normal mechanisms have no place.  There is no “where do I stow the anchor” or “where do I control the RAM signal lights.” There are whole chapters of the USCG instructions (ColRegs) where the thing discussed is not on a HobeeCat. That does not make such boats inadequate; it makes them fun. If you can stop thinking of concurrency in Go as a small group of exquisitely instrumented machines and instead imagine a swarm of ants, you’ll find new and interesting ways to solve problems. They often work even better, and are also more fun. On Wed, Jun 19, 2019 at 9:37 AM Robert Engels  wrote:Side-managed thread/execution context has been around since the concept of a thread. It is highly useful, and is more robust and secure than a Context object passed among methods.If Go had any concept of a "secure runtime" it would be essential, but it doesn't, so you make do with what you have.-Original Message-
From: jake6...@gmail.com
Sent: Jun 19, 2019 11:08 AM
To: golang-nuts 
Subject: [go-nuts] Re: is there a goroutine scope global veriable ?

This has been discussed many times before. Searching "local storage" on this group brings up many discussions, including:https://groups.google.com/d/topic/golang-nuts/Nt0hVV_nqHE/discussionhttps://groups.google.com/d/topic/golang-nuts/_Vv7Bzn8yH4/discussionhttps://groups.google.com/d/topic/golang-nuts/zuWWBHKn6iw/discussionMy take is that GLS could be genuinely useful in a few cases, but would undoubtedly lead to abuse in most cases. In the vast majority of  situations, what you really want to track, or log, is the specific work being done, not actually which goroutine it happens to be running on. For example, tracking a specific request, etc. My advice is to pass around a context, or some other identifying information about the specific work being done. At first this will seem tedious and annoying, but you will likely get used to it.On Tuesday, June 18, 2019 at 10:59:09 PM UTC-4, hui zhang wrote:is there a goroutine scope global veriable ?like  fork a variable from main ?



-- 
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/53512dd1-8c24-460d-9bf5-646ea1e95d0f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.




-- 
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/1187971360.3926.1560962237733%40wamui-berry.atl.sa.earthlink.net.
For more options, visit https://groups.google.com/d/optout.
-- 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 

Re: [go-nuts] Re: is there a goroutine scope global veriable ?

[Henrik Johansson]

On a practical note I think thread local storage is more or less
discouraged in for example Java as well
because it makes all the new shine "reactive" tools break since they make
no guarantees as to which thread you are running on.

That may or may not be relevant to your case but to say that it's standard
practice is probably not true any more.

On Wed, Jun 19, 2019 at 8:49 PM Michael Jones 
wrote:

> For the OP:
>
> A thought to share on the general topic: Go is pioneering a sufficiently
> different model of concurrent computation that it may not make much sense
> to ask for or seek equivalencies with classic thread/process models.
>
> This says nothing against the standard model, nor against the “missing”
> services; it is a note to encourage design in Go along with coding in Go,
> instead of design in C/C++/Java/POSIX/... and a best-effort realization in
> Go.
>
> By way of analogy, I’ve long been involved in boat design and
> construction. We always use a pair Furuno or Simrad RADAR antennas, one of
> long range and one short, to optimize object detection/clutter rejection
> and as a redundancy safety factor. However, when sailing on a HobeeCat,
> i’ve never looked for nor missed the Radar or any other instruments of
> navigation. A HobieCat is just such a different idea of sailing that *all*
> the normal mechanisms have no place.  There is no “where do I stow the
> anchor” or “where do I control the RAM signal lights.” There are whole
> chapters of the USCG instructions (ColRegs) where the thing discussed is
> not on a HobeeCat. That does not make such boats inadequate; it makes them
> fun.
>
> If you can stop thinking of concurrency in Go as a small group of
> exquisitely instrumented machines and instead imagine a swarm of ants,
> you’ll find new and interesting ways to solve problems. They often work
> even better, and are also more fun.
>
> On Wed, Jun 19, 2019 at 9:37 AM Robert Engels 
> wrote:
>
>> Side-managed thread/execution context has been around since the concept
>> of a thread. It is highly useful, and is more robust and secure than a
>> Context object passed among methods.
>>
>> If Go had any concept of a "secure runtime" it would be essential, but it
>> doesn't, so you make do with what you have.
>>
>>
>> -Original Message-
>> From: jake6...@gmail.com
>> Sent: Jun 19, 2019 11:08 AM
>> To: golang-nuts
>> Subject: [go-nuts] Re: is there a goroutine scope global veriable ?
>>
>> This has been discussed many times before. Searching "local storage" on
>> this group brings up many discussions, including:
>>
>> https://groups.google.com/d/topic/golang-nuts/Nt0hVV_nqHE/discussion
>> https://groups.google.com/d/topic/golang-nuts/_Vv7Bzn8yH4/discussion
>> https://groups.google.com/d/topic/golang-nuts/zuWWBHKn6iw/discussion
>>
>> My take is that GLS could be genuinely useful in a few cases, but would
>> undoubtedly lead to abuse in most cases. In the vast majority of
>> situations, what you really want to track, or log, is the specific work
>> being done, not actually which goroutine it happens to be running on. For
>> example, tracking a specific request, etc. My advice is to pass around a
>> context, or some other identifying information about the specific work
>> being done. At first this will seem tedious and annoying, but you will
>> likely get used to it.
>>
>>
>> On Tuesday, June 18, 2019 at 10:59:09 PM UTC-4, hui zhang wrote:
>>>
>>> is there a goroutine scope global veriable ?
>>> like  fork a variable from main ?
>>>
>> --
>> 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/53512dd1-8c24-460d-9bf5-646ea1e95d0f%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>>
>> --
>> 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/1187971360.3926.1560962237733%40wamui-berry.atl.sa.earthlink.net
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
>
> *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