[go-nuts] Re: Why there is a so great performance penalty when the usage combines LockOSThread and channel?

Sorry :) This a mistake here: > It's perf output is about 1000,000 ops/sec :) > > But when you uncomment the runtime.LockOSThread() at line 24(the beginning > at func call_srv),it goes so slow to *100,000/sec* and the cpu usage of > kernel goes into madness. > > Actually it should be 100,000

[go-nuts] Why there is a so great performance penalty when the usage combines LockOSThread and channel?

Here is the minimal test case 0: package main import "fmt" import "runtime" type callRet struct { ret int } type callIn struct { ret_chan *chan *callRet arg1 int } func caller(call_in_c *chan *callIn, arg1 int) int { ret_c := make(chan *callRet) ci := callIn{_c,

Re: [go-nuts] Timezone parsing discrepancy

The last sentence of the time.Parse function is "To avoid such problems, prefer time layouts that use a numeric zone offset, or use ParseInLocation." It specifically refers to using "named" time zones (such as PST) instead of offsets, like -0700. It also recommends

[go-nuts] Re: Reflect Struct Comparison

can someone attach the improved and efficient code? On Friday, March 30, 2012 at 5:29:52 PM UTC+5:30, Luke Mauldin wrote: > > I have the the task of comparing two structs (of the same type) for > equality and returning the field level differences. One of the > restrictions is that I only have

[go-nuts] Timezone parsing discrepancy

Hello, I'm having some difficulty with timezones and date parsing. https://golang.org/pkg/time/#Parse says that: const longForm = "Jan 2, 2006 at 3:04pm (MST)" t, _ := time.Parse(longForm, "Feb 3, 2013 at 7:54pm (PST)") fmt.Println(t) should produce: 2013-02-03 19:54:00 -0800 PST but

Re: [go-nuts] Re: Best practice when creating temporary files

Where I was going was that's an assumption based on OS specifics; some do e.g. most Linux flavors but not all OS's do at least by default, so its best to avoid the assumption that it will happen. Absolutely agree that crashes happen, but this thread was about standard cleanup after a program

Re: [go-nuts] Dynamic linking against individual golang standard libraries

On Sun, Nov 20, 2016 at 1:22 PM, Parker Evans wrote: > > In order to do this kind of thing, do I need to manually figure out > dependencies and then setup appropriate linker flags? Yes, pretty much. It may help a bit to look at go/build/deps_test.go. Ian -- You received

Re: [go-nuts] pointer value not updated when called as interface?

Thank you. I got it now. // only red part *resp.(*string) // string pointer (type) *resp.(*string) // convert interface type to string pointer type *resp.(*string) // *dereferences* the pointer On Monday, November 21, 2016 at 6:40:25 PM UTC+1, Sathish VJ wrote: > > if resp is an

[go-nuts] Re: Memory usage and go tool pprof

What is "real"? 65Gb has been asked from the OS, and it gave that much to the runtime. But it used only 25Gb of it. Maybe even released some to the OS, but maybe that did not took that. Is the 25Gb really needed and used for good? The OOM suggests that for moments your program allocated much

[go-nuts] Re: Interface vs first-class function

With a nod to Chris's excellent presentation, this may be an example of Go breaking its own orthogonality rules for the sake of being more consistent (the rule of least surprise) There is a strong overlap between an interface with a single method and a function value, Tomás Senart spoke about

[go-nuts] Re: Interface vs first-class function

A few other thoughts on this: 1 - Method values mean that you can get a function type that accesses state without closures over local variables: a := {} // b is a SomethingDoer function b := a.DoSomething e.g. https://play.golang.org/p/SVY8rQ8WR_ 2 - Method values also mean that multiple

Re: [go-nuts] Re: Where should interfaces live?

My vote would be "it depends" :) You mentioned several different instances of tradeoffs: * I find io.Writer a bit special, because of it's pervasiveness; let's talk about image.Image, which is probably closer to what you're asking. It makes sense for the image package to bundle the Image

[go-nuts] Re: [Help] In a multi-threads application, when main function spins, the whole application hangs up

Thank James! As I am very new to golang, I just write tons of micro applications to study its feature. :-) On Monday, November 21, 2016 at 6:44:50 PM UTC-1, James Bardin wrote: > > > On Monday, November 21, 2016 at 2:23:37 PM UTC-5, zhaoguo wang wrote: >> >> Hi all, >> >> I wrote a simple

[go-nuts] Re: [Help] In a multi-threads application, when main function spins, the whole application hangs up

On Monday, November 21, 2016 at 2:23:37 PM UTC-5, zhaoguo wang wrote: > > Hi all, > > I wrote a simple application: the main function creates two goroutines, > while these two goroutines use RPC to do simple communication continually. > > I found > *if the main function falls into a busy loop

[go-nuts] Re: Where should interfaces live?

My vote is for "in the package that needs them" On Tuesday, 22 November 2016 02:30:21 UTC+11, Vorn Mom wrote: > > Sorry if it was asked before, but where should interfaces live? > >- In the package that contains an implementation of it. >- In its own package. >- or in the package that

[go-nuts] Re: Best practice when creating temporary files

One approach that I use is to make new invocations of the program try to clean up after older ones. For example, if you name your temp directories with a particular pattern, you can delete old directories on start up. Ideally you _should_ try to clean up in the same process, but it isn't

[go-nuts] [Help] In a multi-threads application, when main function spins, the whole application hangs up

Hi all, I wrote a simple application: the main function creates two goroutines, while these two goroutines use RPC to do simple communication continually. I found *if the main function falls into a busy loop after creating the two goroutines, * *the whole application will hang up after

[go-nuts] Re: Merging Data Structures in Go

What is the intended use-case for this? Depending on the purpose, you might have a look at mergo, https://github.com/imdario/mergo as it does something similar, mostly for pulling configuration settings from multiple places and combining them with defaults. For JSON maps, there is

Re: [go-nuts] Re: Best practice when creating temporary files

It's fine to try, but you should design your entire system with the assumption that your program may crash at any moment and leave something around. This is why the OS cleans up /tmp. Thomas On Mon, Nov 21, 2016 at 9:01 AM Steven Hartland wrote: > That's a bad

Re: [go-nuts] pointer value not updated when called as interface?

if resp is an interface, then resp.(string) *type asserts* it into a string. And that will be ok if the underlying type is a string. In the question that I asked, the underlying type was not a string, but a pointer to a string. So he type asserted it into a pointer of string type.

Re: [go-nuts] pointer value not updated when called as interface?

Whats is the meaning of *resp.(*string) = "abcd" . I have not seen this before. -- 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

[go-nuts] Memory usage and go tool pprof

Hello! I'm a golang newbie, so could anyone help me with strange memory allocation by my program. What I have from "runtime/pprof": > Entering interactive mode (type "help" for commands) > (pprof) top > 25987.89MB of 26181.92MB total (99.26%) > Dropped 59 nodes (cum <= 130.91MB) > flat

[go-nuts] Re: Best practice when creating temporary files

I already noted that in my very first post, "How do I clean up? As I said, the app does not persist (so I can't defer os.Remove)" I guess I wasn't quite clear about my intentions, so never mind, I'll just handle it somehow. Thanks all for your suggestions. On Monday, 21 November 2016

Re: [go-nuts] Re: Best practice when creating temporary files

That's a bad assumption, you should always clean up after yourself. On 21/11/2016 16:57, Val wrote: OK, I had overlooked the fact that cleanup is important to you, which makes sense for security and to save disk space early. TempFile, TempDir don't do the cleanup, but the OS will sooner or

[go-nuts] Re: Best practice when creating temporary files

OK, I had overlooked the fact that cleanup is important to you, which makes sense for security and to save disk space early. TempFile, TempDir don't do the cleanup, but the OS will sooner or later. Here is my new suggestion for a file

[go-nuts] Where should interfaces live?

Sorry if it was asked before, but where should interfaces live? - In the package that contains an implementation of it. - In its own package. - or in the package that needs it. The standard library is not consistent. For example: - io.Writer is defined in a package that also has an

[go-nuts] Re: Best practice when creating temporary files

That's my current code, I just wanted to double check that it's the proper one (ie that the cleanup actually happens), since some of my temp files can be fairly large. On Friday, 18 November 2016 15:54:36 UTC, Val wrote: > > Obtain a new temp file : > tmpfile, err := ioutil.TempFile("", "") >