Re: [go-nuts] What are the reasonable reasons to use pointers?

On 1/1/19 12:34 PM, 伊藤和也 wrote: > What are the reasonable reasons to use pointers? Are pointers neseccary? "All problems in computer science can be solved by another level of indirection" -- David Wheeler Happy New Year ;-) -- You received this message because you are subscribed to the

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

On 09/28/2018 03:14 PM, Peter Mogensen wrote: > In other words.. using a map as index into another datastructure without > the map values being considered by the garbage collector as references. I just quickly read about the java.util.WeakHashMap and it says that the keys are th

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

On 09/28/2018 03:43 PM, Ian Lance Taylor wrote: > That statement is not subject to change. Note that that statement > does not say that if p1 and p2 are pointer values, and that p1 == p2, > that uintptr(unsafe.Pointer(p1)) == uintptr(unsafe.Pointer(p2)). You > must not take intuitions from

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

On 09/28/2018 03:29 PM, Robert Engels wrote: > Use the GC as is unless you have a large static object set, it could work for > that... That was a part of the whole premise (see subject). A huge number of same type/size objects. /Peter -- You received this message because you are

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

On 09/28/2018 03:24 PM, Robert Engels wrote: > If you have a object reference then the object is going to tracked by the GC > anyway, no matter where it is referenced from, so you are not saving > anything, as that reference still must be somewhere... ... yes. I haven't really done

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

On 09/28/2018 03:18 PM, Tamás Gulácsi wrote: > > This is not that. > My idea could maybe be restated simpler as having a huge double-linked > list of sync.Pool objects and using wanting to supplement it by a map > index, but avoiding storing pointers in the map. > > > There's

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

On 09/28/2018 03:11 PM, Robert Engels wrote: > His statement is correct. First of all, a weak reference in java is not > like a weak pointer in C++, at least they are not needed to break > cycles, as the GC is immune to that issue. The difference is that a weak > hashmap uses weak references to

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

On 09/28/2018 02:53 PM, Henrik Johansson wrote: > How is storing unintptrs in a map different from say java.util.WeakHashMap? > The data pointed to by the uintptrs can at any given time have been > reclaimed by the GC much the same as weak references in Java. > > I am not saying you are using

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

On 09/28/2018 02:04 PM, Robert Engels wrote: > This is in no way similar to weak references in Java. Weak references > are safe and appropriate for many caching data structures. The code idea > presented here is not related.  Correct. I've used weak references in other languages (not Java) to,

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

On 09/28/2018 09:39 AM, Dan Kortschak wrote: > > I don't understand what you are asking. First, uintptr is not a pointer > type, it's an integer type that is the same size as a pointer and that > can be interconverted with an unsafe.Pointer. If you hold a uintptr > that was converted from an

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

On 09/28/2018 09:13 AM, Henrik Johansson wrote: > This sounds much like the trickery people have used both successfully > but also disastrously using weak references in Java. > Is that where you got the idea from? No. I think I mentioned in my first post where I got the idea from. I haven't

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

On 09/28/2018 08:17 AM, Peter Mogensen wrote: > > > On 09/28/2018 03:04 AM, keith.rand...@gmail.com wrote: >> Objects returned by Get() are not special in any way. They will be GCd >> just like an object returned by new(). In fact, they will often be jus

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

On 09/28/2018 03:04 AM, keith.rand...@gmail.com wrote: > Objects returned by Get() are not special in any way. They will be GCd > just like an object returned by new(). In fact, they will often be just > a new()'d object. > There is no association of such an object with the pool.  A pool is

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

On 09/27/2018 11:12 PM, Dan Kortschak wrote: > Unless you are holding a real pointer to the value, they will have no > root to hold them and so will by GC'd. Also if the pointer is returned by Pool.Get() ? That's probably one of the main questions here. Will an object from sync.Pool which have

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

On 09/27/2018 07:44 PM, Francis wrote: > I believe the pool does not track the objects that it returns from a > call to `Get()`. I would be surprised if it did track these objects. > There is no real need for it to track these objects. Exactly, that was my point. Else there would be no reason

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

On 09/27/2018 07:19 PM, Francis wrote: > It is true that uintptr is not looked at by the garbage collector. This > will definitely reduce your GC costs. But there is no way (that I know > of) to convert your uintptr back into a *Object that is safe. I assume of course that we know that all

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

On 09/27/2018 03:58 PM, Robert Engels wrote: > It wasn’t necessarily a warning to you :) > > It comes from the days of GC bashing in Java and so everyone tried to > manually write garbage free programs using pools and it had a bad effect on > both performance and reliability. GC is there for

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

On 09/27/2018 03:25 PM, Robert Engels wrote: > Based on my experience and I believe many others, I would caution against the > use of pools. Although it can be useful for objects that are very expensive > to create/initialize using it in a more general case just to improve GC can > be

[go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

On 09/27/2018 03:12 PM, Ian Davis wrote: > > > On Thu, 27 Sep 2018, at 2:04 PM, Peter Mogensen wrote: >> >> Of course... it requires that you handle any collisions in hashing the >> string key to an int yourself, but wrt. the value I curious if anyone >>

[go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

Hi, I noticed the GC fix which avoids scanning maps if both key and value are not pointer types. [1] and see it used [2] and discussed [3] So... Initially, I figured this was not worth thinking too much about, but then I came to thing about the relatively common use case where your map value is

Re: [go-nuts] Re: Snapshot data with Go

On 09/16/2018 12:12 PM, Kasun Vithanage wrote: > Yes, forking is done using the OS. I was thinking of a workaround with go > The reason this works in (say) redis, is the copy-on-write feature of the kernel you get with the fork. You would have to implement all this in userspace to make a

Re: [go-nuts] syscall.SetNonblock stopped working in Go 1.9.3

On 2018-01-25 16:18, Ian Lance Taylor wrote: > On Thu, Jan 25, 2018 at 7:04 AM, Max wrote: >> Also, os.File.Fd() having side effects seems very unexpected and surprising >> at least to me. .File() on a network conn have had that effect. > I found it very

Re: [go-nuts] Dereferencing a pointer pointer interface value

On 2018-01-13 17:06, Peter Mogensen wrote: > But I can't really see technical reasons why one could not in principle > make a language operator, which worked for any interface{..} being of > type **T for input and *T for output. - and having that compile time > checked. Hmm

Re: [go-nuts] Dereferencing a pointer pointer interface value

On 2018-01-13 13:28, Axel Wagner wrote: > Go /has/ this operator, it is spelled "*" and is a unary operator with > even more power: It can turn a general *T into a * for any T. > > Say, you'd have the function you want, Alex, This is what I want - or rather, what I'm thinking of:

Re: [go-nuts] Dereferencing a pointer pointer interface value

On 2018-01-13 01:37, 'Axel Wagner' via golang-nuts wrote: > uhm, there is a bit of a mix-up with the yes-vs-no thing and negating. > I'm apparently a bit tired, disregard the actual "no" and focus on the > rest of the reply, explaining why what you want can't be done :) I must admit, I'm

Re: [go-nuts] Dereferencing a pointer pointer interface value

On 2018-01-13 01:35, Axel Wagner wrote: > But the answer to 2 is "no, not in a type-safe way". It necessarily > requires reflection. Even if we'd assume we somehow magically know that > the dynamical value of the interface is some pointer type. That doesn't > actually help us, in any reasonable

Re: [go-nuts] Dereferencing a pointer pointer interface value

On 2018-01-12 22:22, Axel Wagner wrote: > Yes, you can *test* if the dynamic value has a specific type (and > extract it if so). That is not the same as operating on the dynamic > value (e.g. by dereferencing it) *without* knowing its type. I know I can test the type. But the issue was

Re: [go-nuts] Dereferencing a pointer pointer interface value

On 2018-01-12 19:09, 'Axel Wagner' via golang-nuts wrote: > One would think the result is rather well defined. > > > It's not. The value in the interface doesn't have to be a pointer, so > this is, in general, not defined at all. No, but it's not like you cannot ask about interface{} in

[go-nuts] Dereferencing a pointer pointer interface value

Hi, I somehow ended up with an interface{} value being a **SomeStruct{} ... and I need to dereference it to an interface{} holding *SomeStruct{} in a generic way (ie. without knowing about the type SomeStruct) I'm not at all sure this is good idea or the right way for the specific code, but out

Re: [go-nuts] [urgent] need aguments to justify use of Go for a scientific application

On 2017-12-06 10:56, Christophe Meessen wrote: > The main opposing arguments are > - everybody uses python in astrophysics > - it is very easy to find someone who knows python > - risk that I, sole Go programmer, might become unavailable And those are important arguments - especially if the

Re: [go-nuts] net/http: Server closeIdleConns does not close StateNew connections

On 2017-11-13 21:16, André Carvalho wrote: > I also ran into this issue recently. I think this is a dup > of https://github.com/golang/go/issues/21204. This issue can be > mitigated if you set some reasonable ReadTimeout on the http.Server, > which causes the http.StateNew connection to timeout

Re: [go-nuts] graceful restart of app with more than one tcp Listener

On 2017-11-07 15:28, Vasiliy Tolstov wrote: > I know about it, but > https://github.com/rcrowley/goagain/issues/12 cant handle multiple listeners > https://godoc.org/github.com/facebookgo/grace/gracenet does not > support close the listener > https://github.com/fvbock/endless works with http ,

Re: [go-nuts] git submodule vs normal go vendoring

On 2017-10-01 06:38, JM wrote: > can anyone tell me the pros/cons of using git submodule update instead > of godep govendor etc... ? > > git submodule update --init --recursive Your build depend on that command succeeding. If sub-repos are not under your control that can be a serious problem

Re: [go-nuts] Should we stop using a global logger?

On 2017-08-25 12:53, Henrik Johansson wrote: > Yes it works ok we have done it as well but a common interface wouldbe > convenient. Especially when opentracing whose Go libs seems to take off > nicely with afaik a common interface. Logging seems even simpler. > > I have started to use Zap

Re: [go-nuts] Should we stop using a global logger?

On 2017-08-25 10:45, Henrik Johansson wrote: > Me neither but it can be very neat occasionally. > > Agreed and it also applies fine things like Tracing. > But logger? If you change logger implementation you have to have a > wrapper or you have to change the type conversions everywhere. But

Re: [go-nuts] Should we stop using a global logger?

On 2017-08-25 08:31, Henrik Johansson wrote: > How do you code for storing a logger in context.Value? The same usual > issues with lacking a shared logger interface happens or did I miss > something neat? > I try not to do logging from libraries. So logging (and the logger interface) is

Re: [go-nuts] Re: Should we stop using a global logger?

On 2017-08-25 05:58, Dave Cheney wrote: >> Should we stop using a global logger? > > Yes[1] > > 1. https://dave.cheney.net/2017/01/26/context-is-for-cancelation > fair point... It can be very tempting though. Especially dealing with an HTTP middleware stack where you need handlers to log and

Re: [go-nuts] Should we stop using a global logger?

On 2017-08-25 05:38, buchanae.o...@gmail.com wrote: > - We create a child logger instance which has the ID preconfigured, and > pass that to some function calls. [3] I think several log packages has the feature build in. > instances everywhere. I think we can make either work, and so far >

Re: [go-nuts] Built-in log Package

On 2017-08-17 09:24, dc0d wrote: > Logging from a specific place in code helps with finding out /where/ the > error happened. And doing that manually is cumbersome. I for one can not > give-up on this because it makes fixing things super fast. github.com/pkg/errors ...solves many of those

Re: [go-nuts] Built-in log Package

On 2017-08-14 18:36, dc0d wrote: > Another question that I failed to answer properly (by myself) is: are > metrics same as logs? Or they are a higher level concept (which also can > be logged)? And should logging be in charge of delivering metrics (seems > it can be)? Depends... I guess. I

Re: [go-nuts] Built-in log Package

On 2017-08-14 11:04, dc0d wrote: > That may be (still IMH-Experience in the majority of cases, this is the > proper default to go). > > But the main concern to express here is, the default logger should > accept an interface like /Output/ instead of /io.Writer/. I would agree, if not for the

Re: [go-nuts] How do you create and use shared libraries in Go?

On 2017-06-26 09:37, st ov wrote: Ruby has Gems and .NET has DLLs. How do you package and share libraries in Go? Gems are mainly source files, right? ... Using source libraries in Go is relatively straight forward. For your "package main" programs the easiest is to put the library source in

Re: [go-nuts] Proper Way of Defining a Custom Context

On 2017-05-08 11:55, dc0d wrote: So just Value(...) then? Of-course I've implemented an adapter with no extra fields, just with some methods to work with Value(...). Yeah...that would be my best advice - unless someone else can demonstrate a clean way to extend context.Context. /Peter

Re: [go-nuts] Proper Way of Defining a Custom Context

On 2017-05-07 11:58, dc0d wrote: What's the proper way of defining a custom context? Is it enough to wrap the methods of parent `context.Context`? I did some experiments trying to extend the context.Context interface. One quickly runs into endless troubles due to the reliance on global

Re: [go-nuts] http.Server handlers seem to stick around forever

On 2017-04-18 17:08, Ken Simon wrote: Yes that's very strange. My impression was that net.Listener.Close() would actually sever the running connections... It won't. That's why Go 1.8 has Server.Close() and even if one was still open, I'm making a new http.Client object, too! Yes. But

Re: [go-nuts] http.Server handlers seem to stick around forever

On 2017-04-18 17:00, Ken Simon wrote: net/http.Server.Close() only exists in golang 1.8... I'm stuck in 1.7 right now so I can't use that. No, but you can do something equivalent with either a connection manager like in the various "graceful" libraries or simply (as also suggested) disable

[go-nuts] Re: Looking for a http router

On 2017-04-16 19:52, Dragos Harabor wrote: Take a look at https://github.com/pressly/chi Yeah... I actually took a very long look at it, but AFAICS it doesn't support custom methods. I could of course just use the any-method Handle() call and do the method logic in the individual handler,

[go-nuts] Looking for a http router

Hi, Having spend quite some time reading up on the available HTTP router/mux-s I a bit surprised that I couldn't find any which: * Just used http.Handler and the Go1.7+ "context" for routing context * Was method aware and allowed for custom methods * Did not only allow strings as router

Re: [go-nuts] godoc does not show from GOPATH/src/vendor

On 2016-12-09 18:39, Sathish VJ wrote: I have my vendor folder like this: $GOPATH/src/vendor. This works for the code. However, godoc does not show the libraries therein. Is there a way I can fix this? Go tools are increasingly allergic to non-standard layouts. You need to put your vendor

Re: [go-nuts] Is there a formal document explain the package search orders in Golang?

On 2016-12-02 22:31, Ian Lance Taylor wrote: On Fri, Dec 2, 2016 at 11:24 AM, gd wrote: It looks, for the official compiler, if the main package is under GOPATH, then the order is: 1. the vendor folder 2. the standard packages 3. GOPATH folder If the main package is

Re: [go-nuts] GOPATH default value in Go 1.8

On 2016-12-01 11:18, Manlio Perillo wrote: I have read the Go 1.8 release notes and I found that now GOPATH has a default value. This is a great thing: I have always I thought that GOPATH is one of the weak point in the Go toolchain, both when I started programming in Go and when I read the Go

Re: [go-nuts] CGO: Go string -> void*/length

On 2016-10-31 15:39, Pietro Gagliardi wrote: Just pass the null-terminated string and use C.int(len(goString)) as the length. Yes... I mentioned that as a somewhat solution. ... it still allocates 1 byte more than needed. /Peter -- You received this message because you are subscribed to

[go-nuts] CGO: Go string -> void*/length

Hi, I was trying to find the official way to pass a Go string to CGO code as a void* (or char*) with explicit length. ... using only one allocation/copy. I could probably just call C.CString(string) and ignore the extra \0 added by CGO, but I'm a little puzzled that there's not a shorthand

Re: [go-nuts] Logging concurrent safe ?

On 2016-10-29 13:37, Łukasz Kostka wrote: Hi. In docs I can see that logger can be safely used in multiple coroutines. I've implemented this, but my program seems to freeze at random. Am I

Re: [go-nuts] Re: Stopping a server

On 2016-10-28 13:32, roger peppe wrote: On 28 October 2016 at 11:03, Nick Patavalis wrote: In fact the worker "w" is a single-use thing much like a context. Yes, that's right. The main difference from a context is that a context provides no way to know when things

Re: [go-nuts] Re: Stopping a server

On 2016-10-28 10:37, roger peppe wrote: FWIW we often use an interface named Worker for long lived processes, including servers: type Worker interface { Kill() Wait() error } Kill asks the worker to die but doesn't block. Wait waits for the worker to die and returns

Re: [go-nuts] Re: Stopping a server

On 2016-10-28 09:09, Nick Patavalis wrote: On Fri, Oct 28, 2016 at 8:15 AM, Peter Mogensen <a...@one.com> wrote: The point being that it's up to the user of the interface how to specific Server implementation should work. Yes, of course, but an interface with just two methods

Re: [go-nuts] Re: Stopping a server

On 2016-10-27 21:34, Nick Patavalis wrote: These is no way to (positively) know when the server will enter the "running state". Think of this sequence: go func () { err := srv.Serve() // or .Start() srvEnd <- err } ... a short time after ... srv.Stop() //

Re: [go-nuts] Re: Stopping a server

On 2016-10-27 19:32, Nick Patavalis wrote: type Server interface { Serve() error // start serving and block until exit Shutdown()// async req. to shutdown, must not block } The "subtle races" I was talking about: What happens if you call "Shutdown()" before you call

Re: [go-nuts] Stopping a server

On 2016-10-27 16:11, Nick Patavalis wrote: I konw that, functionally, this will work. My question is: Does this look like a "reasonable" / "idiomatic" use of contexts? Or will it look "alien" to the user? I'm asking since the documentation of "context" mentions it being used for

Re: [go-nuts] Architect a daemon program

On 2016-10-11 19:09, Tong Sun wrote: I need the program (say, named as`myprog`) to fork into the background (if possible) with the "start" command-line option. What's important is that when `myprog` is called with other command-line options, it will /communicate with the running background

Re: [go-nuts] labeled loop vs for statement inlining

On 2016-08-29 16:59, 'Chris Manghane' via golang-nuts wrote: I can't explain exactly because my explanation is likely very flawed, but the logic you are looking for is in https://github.com/golang/go/blob/320ddcf8344beb1c322f3a7f0a251eea5e442a10/src/cmd/compile/internal/gc/inl.go#L186.

Re: [go-nuts] log.Logger, Why is this not an interface?

On 2016-07-08 20:28, Konstantin Khomoutov wrote: I think I understand your concerns, and actually has nothing to say against them. The only possible (and very real) case is that easy to use full-blown logging tends to be abused in some circles, namely, in the Java world where every freaking

Re: [go-nuts] log.Logger, Why is this not an interface?

On 2016-07-08 19:56, Konstantin Khomoutov wrote: On Fri, 8 Jul 2016 19:14:27 +0200 Peter Mogensen <a...@one.com> wrote: The standard log library doesn't support logging simple "message". At least not in an efficient way. But that's precisely what Zachary is advocating (

Re: [go-nuts] log.Logger, Why is this not an interface?

On 2016-07-08 18:34, Zachary Gershman wrote: I disagree - if you have no need for structured logging, why reach for a library? Stdlib seems to work just fine until you run into a large amount of log output that is mission critical or you want to start shipping these logs off to a third party