[go-nuts] Re: Go package management proposal process

[Lucio]

Probably too obvious a suggestion to be taken seriously, but just in case 
no one else has thought of this, would a "go vendor" command be useful as 
the main objective here?

Lucio.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: src/log/log.go: What makes it expensive in this code of log.go?

[Dave Cheney]

The log package has some benchmarks, maybe make the change and see if it 
makes a difference.

On Wednesday, 7 September 2016 02:46:09 UTC+10, mwor...@gmail.com wrote:
>
> Hey, It's commented "release lock while getting caller info - it's 
> expensive" in source code of /src/log/log.go line:150.
>
> I'm confused with what makes it expensive if we didn't unlock the l.mu ? 
> Does goroutines have context ?
>
> func (l *Logger) Output(calldepth int, s string) error {
> now := time.Now() // get this early.
> var file string
> var line int
> l.mu.Lock()
> defer l.mu.Unlock()
> if l.flag&(Lshortfile|Llongfile) != 0 {
> // release lock while getting caller info - it's expensive.
> l.mu.Unlock()
> var ok bool
> _, file, line, ok = runtime.Caller(calldepth)
> if !ok {
> file = "???"
> line = 0
> }
> l.mu.Lock()
> }
> l.buf = l.buf[:0]
> l.formatHeader(, now, file, line)
> l.buf = append(l.buf, s...)
> if len(s) == 0 || s[len(s)-1] != '\n' {
> l.buf = append(l.buf, '\n')
> }
> _, err := l.out.Write(l.buf)
> return err
> }
>
> AND
>
> What will happen if I moved the _, file, line, ok = 
> runtime.Caller(calldepth) like below? Is better than the upper one ?
>
> func (l *Logger) Output(calldepth int, s string) error {
> now := time.Now() // get this early.
> var file string
> var line int
>
> //moved here
> var ok bool
> _, file, line, ok = runtime.Caller(calldepth)
>
> l.mu.Lock()
> defer l.mu.Unlock()
>
> l.buf = l.buf[:0]
> if l.flag&(Lshortfile|Llongfile) != 0 {
> if !ok {
> file = "???"
> line = 0
> }
> l.formatHeader(, now, file, line)
> }
>
> l.buf = append(l.buf, s...)
> if len(s) == 0 || s[len(s)-1] != '\n' {
> l.buf = append(l.buf, '\n')
> }
> _, err := l.out.Write(l.buf)
> return err
> }
>
> Thanks for all
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: src/log/log.go: What makes it expensive in this code of log.go?

[mworks092]

Yes I closed the issue on github. How about discuss about it here

在 2016年9月7日星期三 UTC+8上午5:33:50，Benjamin Measures写道：
>
> Link to the discussion moved from github: issue #17003 
> 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: What 'select' is doing here?

[Pablo Rozas-Larraondo]

Right! Ok, I understand it now, there's no concurrent evaluation happening. 
And I understand what you meant when evaluating the functions before the 
select statement in your code. 

Thank you very much for your help in understanding this Dave.

Pablo

On Wednesday, September 7, 2016 at 11:51:59 AM UTC+10, Dave Cheney wrote:
>
> The best description i've found comes from the spec, see the "execution of 
> select statement" section.
>
> https://golang.org/ref/spec#Select_statements
>
> The program I rewrote for you is identical to the one you wrote, all the 
> work to evaluate the RHS of the select cases happens "before" the select 
> statement, so if A() sleeps for 100ms, then B() sleeps for 1000ms, the 
> select statement is not executed until both operations have happened.
>
>
> On Wednesday, 7 September 2016 11:48:02 UTC+10, Pablo Rozas-Larraondo 
> wrote:
>>
>> Thanks Dave. It seems though that whatever select chooses to run (A or B) 
>> the program takes 1000 ms to complete. I would expect the program to finish 
>> in 100 ms if A is chosen or 1000 ms in the case of B. I wonder if both 
>> functions are evaluated concurrently no matter which case select chooses. 
>> If this is true, does anyone know what kind of concurrency is the select 
>> statement using underneath?
>>
>> Cheers,
>> Pablo
>>
>> On Wednesday, September 7, 2016 at 8:35:11 AM UTC+10, Dave Cheney wrote:
>>>
>>> Here's the same program rewritten.
>>>
>>> https://play.golang.org/p/ANHNUcPjR2
>>>
>>> If ch is writable, then select pseudo randomly chooses the first or 
>>> second case. The default case is never taken unless ch is blocked, in which 
>>> case the goroutine will block sending to ch indefinitely. 
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: What 'select' is doing here?

[Pablo Rozas-Larraondo]

Thanks Dave. It seems though that whatever select chooses to run (A or B) 
the program takes 1000 ms to complete. I would expect the program to finish 
in 100 ms if A is chosen or 1000 ms in the case of B. I wonder if both 
functions are evaluated concurrently no matter which case select chooses. 
If this is true, does anyone know what kind of concurrency is the select 
statement using underneath?

Cheers,
Pablo

On Wednesday, September 7, 2016 at 8:35:11 AM UTC+10, Dave Cheney wrote:
>
> Here's the same program rewritten.
>
> https://play.golang.org/p/ANHNUcPjR2
>
> If ch is writable, then select pseudo randomly chooses the first or second 
> case. The default case is never taken unless ch is blocked, in which case 
> the goroutine will block sending to ch indefinitely. 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] interactive debugger for go ??

[Tim Hawkins]

If you install the go plugin on intelij (community or paid) and install the
delve debugger, you get a full go ide with interactive visual debugging for
go.

On 7 Sep 2016 00:44, "Bruno Albuquerque"  wrote:

> https://github.com/derekparker/delve
>
> Em ter, 6 de set de 2016 às 13:42, JM  escreveu:
>
>> Will there be a debugger that will allow me to step into my code, watch
>> the flow, and  go line by line  in real time, see values set, etc..?  does
>> this  already exist and  i'm  just not  aware  of  it?  I'm not a full time
>> go dev right now, but use it part time so I may just  not know about this.
>>
>> Worst case  can  someone let  me know what  the most  popular debugger
>> for  go  is (that runs on windows preferably or ubuntu)?
>>
>> 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+unsubscr...@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.
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] help with bazil.org/fuse

[Dan Kortschak]

On Tue, 2016-09-06 at 19:54 +0200, Lars Seipel wrote:
> These are just the flags passed to open. If you want to act on the
> truncate flag, do it once within open, not on every single subsequent
> call to write.
> 
That makes sense. So, we're narrowing down on my field of ignorance.

Am I right in thinking then that I should be just doing
`append((*f)[:off], b...)[:len(*f)+len(b)]` in the body of
Bytes.WriteAt?

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] What 'select' is doing here?

[Dave Cheney]

Here's the same program rewritten.

https://play.golang.org/p/ANHNUcPjR2

If ch is writable, then select pseudo randomly chooses the first or second 
case. The default case is never taken unless ch is blocked, in which case the 
goroutine will block sending to ch indefinitely. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] What 'select' is doing here?

[Pablo Rozas Larraondo]

I'm trying to understand how the 'select' statement works internally. The
execution process of select as described in
https://golang.org/ref/spec#Select_statements says on number 2: "If one or
more of the communications can proceed, a single one that can proceed is
chosen via a uniform pseudo-random selection."

However, in this example: https://play.golang.org/p/1GKsbhES8s

I've defined two cases each calling a different function: A() and B(). When
I execute this code it seems to evaluate both functions (it waits till the
longest sleep in A and B finishes but returns a random 1 or 2).

Does this means that select choses a random case (as stated in the docs)
but evaluates both cases? Does anyone know what kind of concurrency
'select' uses internally to evaluate both functions?

Thanks for your help,
Pablo

Note: The Go Playground doesn't seem to return random responses as the ones
I see when I run the same code on my local computer. It might be related to
internal caching effects.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: help with bazil.org/fuse

[Tommi Virtanen]

Err sorry should have read more. Your panic message was

2016/09/05 02:57:52 fuse: panic in handler for Write [ID=0x25 Node=0x8 
Uid=1000 Gid=1000 Pid=3299] 0x2 17 @31 fl=0 lock=0 ffl=OpenReadWrite: 
runtime error: slice bounds out of range 

so it's the slice that's busted, not the deref.

On Tuesday, September 6, 2016 at 1:16:42 PM UTC-7, Tommi Virtanen wrote:
>
> On Sunday, September 4, 2016 at 8:18:08 PM UTC-7, kortschak wrote:
>
>> Can someone tell me what it is that I'm failing to understand with file 
>> truncation/write and FUSE? 
>>
>
> Doesn't seem to have much to do with FUSE.
>
> goroutine 50 [running]: 
>> bazil.org/fuse/fs.(*Server).serve.func2(0x65e4a0, 0xc4200a4460, 
>> 0xc420042ec8, 0xc420042e1f) 
>> /home/travis/gopath/src/bazil.org/fuse/fs/serve.go:857 +0x1d9 
>> panic(0x5702e0, 0xc420018150) 
>> 
>> /home/travis/.gimme/versions/go1.7.linux.amd64/src/runtime/panic.go:458 
>> +0x243 
>> github.com/ev3go/sisyphus.(*Bytes).WriteAt(0xc42000c680, 0xc42014a050, 
>> 0x11, 0x20fb0, 0x1f, 0x590ba0, 0xc420042901, 0x7fd968d874c0) 
>> /home/travis/gopath/src/github.com/ev3go/sisyphus/sisyphus.go:102 
>> +0x115 
>>
>
>
> https://github.com/ev3go/sisyphus/blob/205b07b1c66176293c0a4d2d52dec9335c5f2ab4/sisyphus.go#L102
>
> Looks like f there is nil. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: job queue with the ability to kill worker processes

[Edward Muller]

There is also: https://github.com/bgentry/que-go

On Tue, Sep 6, 2016 at 12:56 PM Tieson Molly  wrote:

> Thanks Jason,  I was looking for something to handle external processes.
>
>
>
> On Monday, September 5, 2016 at 11:13:59 AM UTC-4, Jason E. Aten wrote:
>>
>> On Thursday, September 1, 2016 at 4:40:50 AM UTC-7, Tieson Molly wrote:
>>>
>>> Are there any go projects that implement a queue where workers that
>>> consume the queue could be tracked and potentially killed if the end user
>>> decides to cancel the job?
>>>
>>
>> I assume you mean across multiple worker processes; possibly all on one
>> host or possibly in a distributed fashion. My goq project, pronounced "go
>> queue",
>>
>> https://github.com/glycerine/goq
>>
>> let's you cancel a job, using "goq kill ". Workers that were
>> started with "goq work" will die after oneshot at work. Workers that were
>> started with "goq work forever" will keep requesting jobs.
>>
>> If you mean within a single process, this is common and readily
>> implemented using channels. The stdlib's "net/context" has even
>> standardized an interface to such requests. I'll keep this short. Feel free
>> to let me know if you meant in-process and need more detail.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: help with bazil.org/fuse

[Tommi Virtanen]

On Sunday, September 4, 2016 at 8:18:08 PM UTC-7, kortschak wrote:

> Can someone tell me what it is that I'm failing to understand with file 
> truncation/write and FUSE? 
>

Doesn't seem to have much to do with FUSE.

goroutine 50 [running]: 
> bazil.org/fuse/fs.(*Server).serve.func2(0x65e4a0, 0xc4200a4460, 
> 0xc420042ec8, 0xc420042e1f) 
> /home/travis/gopath/src/bazil.org/fuse/fs/serve.go:857 +0x1d9 
> panic(0x5702e0, 0xc420018150) 
> 
> /home/travis/.gimme/versions/go1.7.linux.amd64/src/runtime/panic.go:458 
> +0x243 
> github.com/ev3go/sisyphus.(*Bytes).WriteAt(0xc42000c680, 0xc42014a050, 
> 0x11, 0x20fb0, 0x1f, 0x590ba0, 0xc420042901, 0x7fd968d874c0) 
> /home/travis/gopath/src/github.com/ev3go/sisyphus/sisyphus.go:102 
> +0x115 
>

https://github.com/ev3go/sisyphus/blob/205b07b1c66176293c0a4d2d52dec9335c5f2ab4/sisyphus.go#L102

Looks like f there is nil. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: job queue with the ability to kill worker processes

[Tieson Molly]

Thanks Jason,  I was looking for something to handle external processes.  



On Monday, September 5, 2016 at 11:13:59 AM UTC-4, Jason E. Aten wrote:
>
> On Thursday, September 1, 2016 at 4:40:50 AM UTC-7, Tieson Molly wrote:
>>
>> Are there any go projects that implement a queue where workers that 
>> consume the queue could be tracked and potentially killed if the end user 
>> decides to cancel the job?
>>
>
> I assume you mean across multiple worker processes; possibly all on one 
> host or possibly in a distributed fashion. My goq project, pronounced "go 
> queue",
>
> https://github.com/glycerine/goq 
>
> let's you cancel a job, using "goq kill ". Workers that were 
> started with "goq work" will die after oneshot at work. Workers that were 
> started with "goq work forever" will keep requesting jobs.
>
> If you mean within a single process, this is common and readily 
> implemented using channels. The stdlib's "net/context" has even 
> standardized an interface to such requests. I'll keep this short. Feel free 
> to let me know if you meant in-process and need more detail.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] help with bazil.org/fuse

[Lars Seipel]

On Mon, Sep 05, 2016 at 12:47:51PM +0930, Dan Kortschak wrote:
> func (f *RW) Write(ctx context.Context, req *fuse.WriteRequest, resp 
> *fuse.WriteResponse) error {
>   f.mu.Lock()
>   defer f.mu.Unlock()
> 
>   f.mtime = f.fs.now()
> 
>   var err error
>   if req.FileFlags != 0 {
>   err = f.dev.Truncate(req.Offset)
>   if err != nil {
>   return err
>   }
>   }

These are just the flags passed to open. If you want to act on the
truncate flag, do it once within open, not on every single subsequent
call to write.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Negative (BC) dates.

[Bruno Albuquerque]

Ah, yes... That makes sense.

But no, I do not need to represent dates billion years in the past. I was
just testing if things would work by using the limits. I would only need to
have dates down to around a few centuries BC.


Em ter, 6 de set de 2016 às 14:30, Jakob Borg  escreveu:

> Year() returns an int, and the playground is 32 bit, so can't represent
> something smaller than about minus two billion. However if your use case is
> to represent times billions of years in the past I don't think a time.Time
> is the right type. There's the whole business about time zones, leap years
> and so on that time.Time tries to deal with which runs into the fact that a
> calendrical system didn't exist at that time. Astronomy tends to talk about
> Julian years from a given point in time. Perhaps something based on that,
> given that you probably don't need to refer to a time and date in a year
> billions of years ago?
>
> //jb
> On Tue, 6 Sep 2016 at 18:41, Bruno Albuquerque  wrote:
>
>> I was trying to store BC dates in a database and due to various issues
>> with date handling and assumptions about date ranges, I decided to store
>> the date as a int64 number and use time.Unix() to convert it to a time
>> object. This mostly works but I found some weird behavior:
>>
>> https://play.golang.org/p/4zm4pw8bwP
>>
>> Any ideas why this is happening?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Negative (BC) dates.

[Jakob Borg]

Year() returns an int, and the playground is 32 bit, so can't represent
something smaller than about minus two billion. However if your use case is
to represent times billions of years in the past I don't think a time.Time
is the right type. There's the whole business about time zones, leap years
and so on that time.Time tries to deal with which runs into the fact that a
calendrical system didn't exist at that time. Astronomy tends to talk about
Julian years from a given point in time. Perhaps something based on that,
given that you probably don't need to refer to a time and date in a year
billions of years ago?

//jb
On Tue, 6 Sep 2016 at 18:41, Bruno Albuquerque  wrote:

> I was trying to store BC dates in a database and due to various issues
> with date handling and assumptions about date ranges, I decided to store
> the date as a int64 number and use time.Unix() to convert it to a time
> object. This mostly works but I found some weird behavior:
>
> https://play.golang.org/p/4zm4pw8bwP
>
> Any ideas why this is happening?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] interactive debugger for go ??

[Sam Whited]

On Tue, Sep 6, 2016 at 11:42 AM, JM  wrote:
> Will there be a debugger that will allow me to step into my code, watch the
> flow, and  go line by line  in real time, see values set, etc..?  does this
> already exist and  i'm  just not  aware  of  it?  I'm not a full time go dev
> right now, but use it part time so I may just  not know about this.

It's not Go specific, and therefore will have some issues (especially
when you start getting into highly concurrent programs), but GDB works
well enough for me in most cases: https://www.gnu.org/software/gdb/

—Sam


-- 
Sam Whited
pub 4096R/54083AE104EA7AD3

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: [golang-dev] help me with gorutines

[airborne . spatula]

Hello,

You almost had it, just backwards.
In this play, the goroutines are waiting for permission to print their next 
value, printing it, then passing the permission to the other goroutine.
https://play.golang.org/p/LsxOfKihM7
I think that meets your //redact requirements too.

Have fun.

On Tuesday, 6 September 2016 09:20:05 UTC+10, Dave Cheney wrote:
>
> Please redirect this question to golang-nuts. 
>
> On Sun, Sep 4, 2016 at 7:22 AM, Ринат Галиев  > wrote: 
> > Hi, i need to solve the task: 
> > Change the program so that the numbers 1 through 6 were printed to the 
> > console in order. Allowed to amend the sections of code that are marked 
> > commentary «// redact». 
> > https://play.golang.org/p/tUMlHWHfJE 
> > 
> > it is not work: https://play.golang.org/p/hW-9J5YfC4 
> > 
> > i know, that need to use the channels 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "golang-dev" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to golang-dev+...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Broadcasting via channel

[Chris Holland]

One more thing, if you want the wait condition to be grouped in a select{} 
use the .Channel() method to get the channel. The Wait helper method does 
this with a timeout, as an example. After the signal the channel is dead so 
you have to use Channel() again to get the new one. If you're using it as 
say a global heartbeat, so you don't run so many timers.

I primarily use it as Kill conditions and heartbeats.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] src/log/log.go: What makes it expensive in this code of log.go?

[mworks092]

Hey, It's commented "release lock while getting caller info - it's 
expensive" in source code of /src/log/log.go line:150.

I'm confused with what makes it expensive if we didn't unlock the l.mu ? 
Does goroutines have context ?

func (l *Logger) Output(calldepth int, s string) error {
now := time.Now() // get this early.
var file string
var line int
l.mu.Lock()
defer l.mu.Unlock()
if l.flag&(Lshortfile|Llongfile) != 0 {
// release lock while getting caller info - it's expensive.
l.mu.Unlock()
var ok bool
_, file, line, ok = runtime.Caller(calldepth)
if !ok {
file = "???"
line = 0
}
l.mu.Lock()
}
l.buf = l.buf[:0]
l.formatHeader(, now, file, line)
l.buf = append(l.buf, s...)
if len(s) == 0 || s[len(s)-1] != '\n' {
l.buf = append(l.buf, '\n')
}
_, err := l.out.Write(l.buf)
return err
}

AND

What will happen if I moved the _, file, line, ok = 
runtime.Caller(calldepth) like below? Is better than the upper one ?

func (l *Logger) Output(calldepth int, s string) error {
now := time.Now() // get this early.
var file string
var line int

//moved here
var ok bool
_, file, line, ok = runtime.Caller(calldepth)

l.mu.Lock()
defer l.mu.Unlock()

l.buf = l.buf[:0]
if l.flag&(Lshortfile|Llongfile) != 0 {
if !ok {
file = "???"
line = 0
}
l.formatHeader(, now, file, line)
}

l.buf = append(l.buf, s...)
if len(s) == 0 || s[len(s)-1] != '\n' {
l.buf = append(l.buf, '\n')
}
_, err := l.out.Write(l.buf)
return err
}

Thanks for all

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Logging Facade

[yun . zhi . lin]

I was looking around for the same thing and found this: 
https://github.com/ventu-io/slf

I agree with Ian, for simple logs, a interface will suffice. But for 
structured logs with Fields it gets a bit more complicated.

On Sunday, February 1, 2015 at 5:01:13 AM UTC+11, Jérôme LAFORGE wrote:
>
> Hello Gophers,
> Do you know whether logging facade framework exists for Go (as SF4J 
> http://www.slf4j.org/ for Java) ?
> My main goal is to develop one library and let to the final user the 
> choice of logging framework.
>
> Thx in adv.
> Jérôme
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: In case you missed it: language benchmarks for Go 1.7, and language adoption

[sascha.l.teichmann via golang-nuts]

Am Montag, 5. September 2016 15:41:28 UTC+2 schrieb Jason E. Aten:
>
>
> On Wednesday, August 31, 2016 at 8:44:57 AM UTC-7, Eric Johnson wrote:
>>
>>
>> On 8/31/16 2:04 AM, Harald Weidner wrote: 
>> > The Java counterpart of this benchmark does not use the Java build-in 
>> > maps, but imports a map implementation for fixed data types from the 
>> > fastutil project. 
>> > 
>> > http://fastutil.di.unimi.it/ 
>> I hadn't noticed that. That would seem to violate the spirit of the test: 
>> "The work is to use the built-in or library hash table implementation to 
>> accumulate count values - lookup the count for a key and update the 
>> count in the hash table. Don't optimize away the work." 
>>
>
> The description of k-nucleotide does specify that the use of third-party 
> hash table libraries is allowed. See the 
> http://benchmarksgame.alioth.debian.org/u64q/knucleotide-description.html#knucleotide
>  
> :
>
> Some language implementations have hash tables built-in; some provide a 
>> hash table as part of a collections library; some use a third-party hash 
>> table library. (For example, use either khash 
>>  or CK_HT 
>>  for C language 
>> k-nucleotide programs.) The hash table algorithm implemented is likely to 
>> be different in different libraries.
>> The work:
>> The work is to use the built-in *or library hash table* [emphasis mine] 
>> implementation to accumulate count values - lookup the count for a key and 
>> update the count in the hash table.
>
>  
> I tried substituting my own offheap hashtable, open source/available at 
> https://github.com/glycerine/offheap
>
> The version specialized for uint32->uint32 runs about 25% faster on my 
> laptop. I submitted it here:
>
>
> https://alioth.debian.org/tracker/index.php?func=detail=315482_id=100815=413122
>
> Jason
>

Have a look at my version  https://bitbucket.org/s_l_teichmann/knucleotide 
which is nearly on-par with the Java version.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Curiosity in encoding/json mem allocations

[Tonny Staunsbrink]

Hi

I hope this is the right forum for posting this kind of question:
Debugging application performance, I came across JSON stream parsing 
causing a large number of mem allocations. Here's a snippet of code, which 
exemplifies my findings:

var (
 noSpace= `{"Key":"StringValue"}`
 oneSpace   = `{"Key":"StringValue"} `
 twoSpace   = `{"Key":"StringValue" } `
 threeSpace = `{"Key": "StringValue" } `
 fourSpace  = `{"Key" : "StringValue" } `
 fiveSpace  = `{ "Key" : "StringValue" } `
)


func TryJSONStreamParsing(b *testing.B, jsonMsg string) {
 for i := 0; i < b.N; i++ {
 dec := json.NewDecoder(bytes.NewReader([]byte(jsonMsg)))
 t, err := dec.Token()
 if err != nil {
 b.Fatal(err)
 }
 if t != json.Delim('{') {
 b.Fatal("No {")
 }
 for dec.More() {
 t, err = dec.Token()
 if err != nil {
 b.Fatal(err)
 }
 if t == nil {
 b.Fatal("no t")
 }
 }
 }
}
func BenchmarkJSONNoSpace(b *testing.B) {
 TryJSONStreamParsing(b, noSpace)
}
func BenchmarkJSONOneSpace(b *testing.B) {
 TryJSONStreamParsing(b, oneSpace)
}
func BenchmarkJSONTwoSpace(b *testing.B) {
 TryJSONStreamParsing(b, twoSpace)
}
func BenchmarkJSONThreeSpace(b *testing.B) {
 TryJSONStreamParsing(b, threeSpace)
}
func BenchmarkJSONFourSpace(b *testing.B) {
 TryJSONStreamParsing(b, fourSpace)
}
func BenchmarkJSONFiveSpace(b *testing.B) {
 TryJSONStreamParsing(b, fiveSpace)
}



Here's an example output for running that:
BenchmarkJSONNoSpace-450  3166 ns/op1304 
B/op  24 allocs/op
BenchmarkJSONOneSpace-4  50  2995 ns/op1304 B/op   
   24 allocs/op
BenchmarkJSONTwoSpace-4  50  2423 ns/op1200 B/op   
   18 allocs/op
BenchmarkJSONThreeSpace-4   100  2533 ns/op1200 B/op   
   18 allocs/op
BenchmarkJSONFourSpace-4 100  2145 ns/op1104 
B/op  12 allocs/op
BenchmarkJSONFiveSpace-4 100  2069 ns/op1104 
B/op  12 allocs/op

Depending on where the whitespace is put in the JSON message, there are 
very different count of memory allocs.

When comparing memory profiles of the worst case vs. the best case...
Top 7 items in worst case:
   2255615 27.06% 27.06%3074826 36.89%  encoding/json.(*scanner).error
   2064414 24.77% 51.83%6761536 81.12%  encoding/json.(*Decoder).Token
   1573541 18.88% 70.71%8335077   100%  .TryJSONStreamParsing
   1081360 12.97% 83.68%1081360 12.97% 
 encoding/json.(*decodeState).literalStore
819211  9.83% 93.51% 819211  9.83%  strconv.quoteWith
540936  6.49%   100% 540936  6.49%  encoding/json.(*Decoder).refill
 0 0%   100%4156186 49.86%  encoding/json.(*Decoder).Decode

Top 7 items in best case:
   3932219 41.93% 41.93%6762044 72.10%  encoding/json.(*Decoder).Token
   2616008 27.89% 69.82%9378052   100%  .TryJSONStreamParsing
   1835036 19.57% 89.39%1835036 19.57% 
 encoding/json.(*decodeState).literalStore
994789 10.61%   100% 994789 10.61%  encoding/json.(*Decoder).refill
 0 0%   100%1835036 19.57%  encoding/json.(*Decoder).Decode
 0 0%   100% 994789 10.61%  encoding/json.(*Decoder).peek


... it seems that the more compact JSON causes the Decoder to generate 
errors (which are not surfaced and which causes allocations). While the 
JSON with some extra spaces causes a cleaner parse.

Does anyone know why the JSON parser consider missing whitespace after 
values for and error?
Or am I using the json.Decoder incorrectly?

Cheers
Tonny

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] How to build mock class?

[Klaus Ma]

Hi team,

I'm trying to write some mock class for unit test. And in the mock class, 
only part of function are changed. Is there any way to do so? For example, 
in the follow code slice, I'd like to print FakeMyClass.Object's return 
value.

package main

import (
"fmt"
)

type MyClass struct {
}

func (*MyClass) Object() (int) {
return 0
}

func (mc *MyClass) PrintInfo() {
fmt.Printf("%v\n", mc.Object())
}

type FakeMyClass struct {
MyClass
}

func (*FakeMyClass) Object() (int) {
return 1
}

func main() {
mc := {}
mc.PrintInfo()
}



Thanks
Klaus

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] interactive debugger for go ??

[JM]

Will there be a debugger that will allow me to step into my code, watch the 
flow, and  go line by line  in real time, see values set, etc..?  does this 
 already exist and  i'm  just not  aware  of  it?  I'm not a full time go 
dev right now, but use it part time so I may just  not know about this.

Worst case  can  someone let  me know what  the most  popular debugger for 
 go  is (that runs on windows preferably or ubuntu)?

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Negative (BC) dates.

[Bruno Albuquerque]

I was trying to store BC dates in a database and due to various issues with
date handling and assumptions about date ranges, I decided to store the
date as a int64 number and use time.Unix() to convert it to a time object.
This mostly works but I found some weird behavior:

https://play.golang.org/p/4zm4pw8bwP

Any ideas why this is happening?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: In case you missed it: language benchmarks for Go 1.7, and language adoption

['Isaac Gouy' via golang-nuts]

On Wednesday, August 31, 2016 at 4:47:35 PM UTC-7, Tim Hawkins wrote:
>
> I would have expected that aside from informing about general performance, 
> one of the purposes for benchmarks would have been to create pressure for 
> improvement of key features of the laguage, this seems to circumvent this, 
> im not dure what they are trying to achive. Perhaps restrictions on only 
> using the language as distributed and its standard lib would be a healthy 
> constraint to evangelise for. 
>


Do you think using a replacement for Java collections library is at-all 
unusual in-practice?

https://projects.eclipse.org/projects/technology.collections


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Broadcasting via channel

[Chris Holland]

I've needed something similar. Its like a ManualResetEvent in C#, here is 
some test code and the struct I use:

https://play.golang.org/p/mvSMwMZX51

Note running that on playground will timeout due to everything being 
asleep, but this gets the idea across.

On Sunday, September 4, 2016 at 4:29:11 PM UTC-7, Uvelichitel wrote:
>
>
> On 09/05/2016 12:14 AM, Jason E. Aten wrote: 
> > 
> > Or perhaps it is because sync.WaitGroup and sync.Cond (condition 
> > variables) exist. They 
> > aren't select{}-friendly, but they usually do the job. 
> Yes  they aren't select{}-friendly. sync.Cond for example looks like 
> right choice but just blocks. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] crypto/sha1.blockAMD64 taking more CPU on FreeBSD

[Niloy Debnath]

Hi,
  I am running a golang Webserver on Linux and FreeBSD. I have generated 
certificates using SHA1 algo but I have observed different result while 
doing CPU profiling on both the machines. Linux is fine but on FreeBSD 
blockAMD64 is the second highest CPU consumer after syscall.Syscall. It 
looks like it is a blocking call and because of that lot of OS thread is 
getting generated on high load. It is affecting my server performance. 

Is there any idea why it is this taking more CPU on FreeBSD and how I can 
overcome this so that I can get better TPS on FreeBSD.

Regards,
Niloy

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: memory leak with websocket service based on go-socket.io

[aiden0xz]

When user refresh the page, the old websocket conn  will be closed and a 
new one created. 

I do not understand "If the websocket never disconnects, then the goroutine 
will pin all memory it is using." 

The websocekt conn block on read, why will pin all memory?


在 2016年9月6日星期二 UTC+8下午5:22:39，Dave Cheney写道：
>
> You have 4601 goroutines blocked on reading from the websocket
>
> goroutine profile: total 4583
> 1526 @ 0x42d77a 0x42806b 0x4277c9 0x67ffb8 0x680024 0x681861 0x6924e0 
> 0x5b2e5c 0x5b34bc 0x7bc06d 0x7bc1b6 0x7bd237 0x7a2d94 0x45da11
> # 0x4277c8net.runtime_pollWait+0x58   
> 
> /usr/lib/go-1.7/src/runtime/netpoll.go:160
> # 0x67ffb7net.(*pollDesc).wait+0x37   
> 
> /usr/lib/go-1.7/src/net/fd_poll_runtime.go:73
> # 0x680023net.(*pollDesc).waitRead+0x33   
> 
> /usr/lib/go-1.7/src/net/fd_poll_runtime.go:78
> # 0x681860net.(*netFD).Read+0x1a0 
> 
> /usr/lib/go-1.7/src/net/fd_unix.go:243
> # 0x6924dfnet.(*conn).Read+0x6f   
> 
> /usr/lib/go-1.7/src/net/net.go:173
> # 0x5b2e5bbufio.(*Reader).fill+0x10b  
> 
> /usr/lib/go-1.7/src/bufio/bufio.go:97
> # 0x5b34bbbufio.(*Reader).Read+0x1bb  
> 
> /usr/lib/go-1.7/src/bufio/bufio.go:209
> # 0x7bc06c
> bitbucket.org/sjtushi/comet/vendor/github.com/gorilla/websocket.(*Conn).readFull+0x8c
>
>
>
> If the websocket never disconnects, then the goroutine will pin all memory it 
> is using. You probably need to add some timeouts to your application.
>
>
> On Tuesday, 6 September 2016 19:14:29 UTC+10, aide...@gmail.com wrote:
>>
>> I can make sure that the goroutine is exited, because the goroutine count 
>> is stable but the heap count is always increase. You can see more detail 
>> pprof from https://comet.shiyanlou.com/debug/pprof/.
>>
>>
>> 在 2016年9月6日星期二 UTC+8下午5:05:05，Dave Cheney写道：
>>>
>>> Are you sure that goroutines are exiting? You can check this in the 
>>> /debug/pprof handler. It will tell you how many goroutines are currently 
>>> running.
>>>
>>> On Tuesday, 6 September 2016 18:49:29 UTC+10, aide...@gmail.com wrote:

 I think 
 https://gist.github.com/aiden0z/b8cf00953e81f778bd584fa2ff7eaae7#file-server-go-L268
   error 
  is not the core problem. The error is  ignored because the 
 go-socket.io no error returned, see 
 https://github.com/googollee/go-socket.io/blob/master/server.go#L91.

 go 1.6 and 1.7 I have tried, the problem still stands.


 在 2016年9月6日星期二 UTC+8下午4:25:40，Dave Cheney写道：
>
> This error handling looks wrong,
>
>
> https://gist.github.com/aiden0z/b8cf00953e81f778bd584fa2ff7eaae7#file-server-go-L268
>
> Any error from socketio is ignored, and the method always succeeds 
> unconditionally.
>
> Also, which version of Go are you using ?
>
> On Tuesday, 6 September 2016 18:07:42 UTC+10, aide...@gmail.com wrote:
>>
>> I have restart the the websocket service, and collect new callgraph.
>>
>> 1. in-use heap callgraph 
>>
>>
>> 
>>
>> 2. heap alloc callgraph
>>
>>
>> 
>>
>>
>>
>> 3. source code, pls see gist  
>> https://gist.github.com/aiden0z/b8cf00953e81f778bd584fa2ff7eaae7
>>
>>
>>
>> 在 2016年9月6日星期二 UTC+8下午3:42:06，Dave Cheney写道：
>>>
>>> Are you sure that goroutines are exiting? You can check this in the 
>>> /debug/pprof handler. It will tell you how many goroutines are 
>>> currently 
>>> running. 
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: memory leak with websocket service based on go-socket.io

[Dave Cheney]

Are you sure that goroutines are exiting? You can check this in the 
/debug/pprof handler. It will tell you how many goroutines are currently 
running.

On Tuesday, 6 September 2016 18:49:29 UTC+10, aide...@gmail.com wrote:
>
> I think 
> https://gist.github.com/aiden0z/b8cf00953e81f778bd584fa2ff7eaae7#file-server-go-L268
>   error 
>  is not the core problem. The error is  ignored because the go-socket.io 
> no error returned, see 
> https://github.com/googollee/go-socket.io/blob/master/server.go#L91.
>
> go 1.6 and 1.7 I have tried, the problem still stands.
>
>
> 在 2016年9月6日星期二 UTC+8下午4:25:40，Dave Cheney写道：
>>
>> This error handling looks wrong,
>>
>>
>> https://gist.github.com/aiden0z/b8cf00953e81f778bd584fa2ff7eaae7#file-server-go-L268
>>
>> Any error from socketio is ignored, and the method always succeeds 
>> unconditionally.
>>
>> Also, which version of Go are you using ?
>>
>> On Tuesday, 6 September 2016 18:07:42 UTC+10, aide...@gmail.com wrote:
>>>
>>> I have restart the the websocket service, and collect new callgraph.
>>>
>>> 1. in-use heap callgraph 
>>>
>>>
>>> 
>>>
>>> 2. heap alloc callgraph
>>>
>>>
>>> 
>>>
>>>
>>>
>>> 3. source code, pls see gist  
>>> https://gist.github.com/aiden0z/b8cf00953e81f778bd584fa2ff7eaae7
>>>
>>>
>>>
>>> 在 2016年9月6日星期二 UTC+8下午3:42:06，Dave Cheney写道：

 Are you sure that goroutines are exiting? You can check this in the 
 /debug/pprof handler. It will tell you how many goroutines are currently 
 running. 
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: memory leak with websocket service based on go-socket.io

[Dave Cheney]

Also, heap released will not grow until you stop the memory leak and enough of 
the heap remains idle for more than 10 minutes. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: memory leak with websocket service based on go-socket.io

[Dave Cheney]

Are you sure that goroutines are exiting? You can check this in the 
/debug/pprof handler. It will tell you how many goroutines are currently 
running. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: memory leak with websocket service based on go-socket.io

[aiden0xz]

I has installed the pprof handler and also opened the gc debug. The HeapSys 
in  /debug/pprof/heap page is aways increase,  the HeapReleased aways is 0. 
The gc debug log show that the scvg# is not release any memory.

If the runtime.goexit be called, the goroutine will be return. But why the 
memory own to the goroutine not release after the goroutine finished? From 
the callgraph we can see that the runtime.goexit own much heap.

MemStats from /pprof/heap page:

# runtime.MemStats
# Alloc = 211882848
# TotalAlloc = 1640254736
# Sys = 315858600
# Lookups = 51944
# Mallocs = 5738397
# Frees = 4574009
# HeapAlloc = 211882848
# HeapSys = 279576576
# HeapIdle = 56934400
# HeapInuse = 222642176
# HeapReleased = 0
# HeapObjects = 1164388
# Stack = 19267584 / 19267584
# MSpan = 3026880 / 3194880
# MCache = 4800 / 16384
# BuckHashSys = 1483005
# NextGC = 290484807





在 2016年9月6日星期二 UTC+8下午2:49:14，Dave Cheney写道：
>
> Your operating system may not be reporting memory correctly. To get the 
> accurate report of the memory that your go process uses 
>
> http://talks.godoc.org/github.com/davecheney/presentations/seven.slide#23
>
> Install the pprof handler, and scroll to the bottom of 
>
> go tool pprof http://localhost:3999/debug/pprof/heap
>
> The memory statistics will be reported at the bottom
>
> # HeapSys = 4882432
>
>
> ^ this is the number of bytes your operation system has given to the Go 
> process.
>
>
> On Tuesday, 6 September 2016 16:37:45 UTC+10, aide...@gmail.com wrote:
>>
>> Build with -race flag report nothing.  Something is interesting is that 
>> in the dev env the gc will release the memory, but in product env the 
>> memory seems is not release to OS. 
>>
>>
>>
>> 在 2016年9月6日星期二 UTC+8下午2:05:38，Dave Cheney写道：
>>>
>>> runtime.goexit is the bottom most stack frame of any running goroutine. 
>>> When the caller of runtime.goexit returns, this function will clean up the 
>>> goroutine. 
>>>
>>> If you are not leaking goroutines, then your application must be keeping 
>>> too much memory live, possibly in a shared map.
>>>
>>> It's probably also a good idea to build your application with the -race 
>>> detector and fix any issues that it repors.
>>>
>>> On Tuesday, 6 September 2016 15:56:04 UTC+10, aide...@gmail.com wrote:

 The number of goroutines is normal., but the memory continue increase. 
 I did not understand why the runtime.goexit took so many memory.


 在 2016年9月6日星期二 UTC+8上午11:07:42，Dave Cheney写道：
>
> It looks like your application is using 4.5gb of ram. Check the number 
> of sockets and goroutines you have running. If there are no timeouts then 
> the goroutines could remain alive pinning a lot of memory. 



-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: memory leak with websocket service based on go-socket.io

[aiden0xz]

Build with -race flag report nothing.  Something is interesting is that in 
the dev env the gc will release the memory, but in product env the memory 
seems is not release to OS. 



在 2016年9月6日星期二 UTC+8下午2:05:38，Dave Cheney写道：
>
> runtime.goexit is the bottom most stack frame of any running goroutine. 
> When the caller of runtime.goexit returns, this function will clean up the 
> goroutine. 
>
> If you are not leaking goroutines, then your application must be keeping 
> too much memory live, possibly in a shared map.
>
> It's probably also a good idea to build your application with the -race 
> detector and fix any issues that it repors.
>
> On Tuesday, 6 September 2016 15:56:04 UTC+10, aide...@gmail.com wrote:
>>
>> The number of goroutines is normal., but the memory continue increase. I 
>> did not understand why the runtime.goexit took so many memory.
>>
>>
>> 在 2016年9月6日星期二 UTC+8上午11:07:42，Dave Cheney写道：
>>>
>>> It looks like your application is using 4.5gb of ram. Check the number 
>>> of sockets and goroutines you have running. If there are no timeouts then 
>>> the goroutines could remain alive pinning a lot of memory. 
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: In case you missed it: language benchmarks for Go 1.7, and language adoption

['Isaac Gouy' via golang-nuts]

On Wednesday, August 31, 2016 at 6:31:05 AM UTC-7, Peter Herth wrote:
>
> And, as this very benchmarking site is far too often abused to talk down 
> on languages, just because they have some bad test results, we as the Go 
> community should try to get the fastest results there - most other programs 
> are not very idiomatic or reasonable even. 
>


When the benchmarks game is abused to talk down on Go, that's also an 
opportunity to talk up the benefits of Go.

"*… *the versions of the C code we've pickled in our repo are not even 
close to the fastest. They were chosen for clarity and simplicity for easy 
comparison *by us* with equivalent Go code."

https://groups.google.com/d/msg/golang-nuts/CF5wyVEjEaY/KRgzpjdH3fAJ

Recently the Chapel group did much the same.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: memory leak with websocket service based on go-socket.io

[Dave Cheney]

runtime.goexit is the bottom most stack frame of any running goroutine. 
When the caller of runtime.goexit returns, this function will clean up the 
goroutine. 

If you are not leaking goroutines, then your application must be keeping 
too much memory live, possibly in a shared map.

It's probably also a good idea to build your application with the -race 
detector and fix any issues that it repors.

On Tuesday, 6 September 2016 15:56:04 UTC+10, aide...@gmail.com wrote:
>
> The number of goroutines is normal., but the memory continue increase. I 
> did not understand why the runtime.goexit took so many memory.
>
>
> 在 2016年9月6日星期二 UTC+8上午11:07:42，Dave Cheney写道：
>>
>> It looks like your application is using 4.5gb of ram. Check the number of 
>> sockets and goroutines you have running. If there are no timeouts then the 
>> goroutines could remain alive pinning a lot of memory. 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.