Re: [go-nuts] Linux, unix.Capset, and runtime.LockOSThread

On Thu, Feb 13, 2020 at 1:14 PM Caleb Spare wrote: > > Hi! I have a Linux-specific question about capabilities, threads, and > syscalls. > > I have a Go program which runs other programs with specific > capabilities set. It basically does the following: > > cmd := exec.Command(...) > runtime.Lock

Re: [go-nuts] What are finalizers missing?

This actually sounds like a decent Go library - something that monitor open file handles (or other registered resources) of the process, and then forces a finalizer stage before the OS limits would be hit. > On Feb 14, 2020, at 6:24 PM, robert engels wrote: > > One other note - I am not a fan

Re: [go-nuts] What are finalizers missing?

One additional point, SoftReferences are a different matter - they make dynamic caches in large complex system easier to implement if not a bit more unpredictable. > On Feb 14, 2020, at 6:24 PM, robert engels wrote: > > One other note - I am not a fan of PhantomReferences/Cleaners. As per this

Re: [go-nuts] What are finalizers missing?

One other note - I am not a fan of PhantomReferences/Cleaners. As per this thread https://groups.google.com/forum/#!topic/golang-nuts/9br5GgucQcU I agree that Finalizers are much simpler to understand and deal with. I think this

Re: [go-nuts] What are finalizers missing?

You are correct this it is not a silver bullet, but one thing to note about Java - at the stdlib level, if it attempts to allocate a resource and that returns a 'resource exhausted' (at least for memory), it will force a GC, at which point the PhantomReferences processing is forced to occur, allowi

[go-nuts] Re: What are finalizers missing?

I found a relevant blog post by David Crawshaw that touches on the topic of a garbage collector that can be extended to understand resources other than Go-managed memory: https://crawshaw.io/blog/tragedy-of-finalizers On Fri, Feb 14, 2020 at 11:09 AM Tyler Compton wrote: > The conventional wisdo

Re: [go-nuts] What are finalizers missing?

Thanks for the pointer! I took a look at PhantomReferences and Cleaners, and I see how they could be a more robust way to free resources for an object. However, I don't see a mechanism by which they can express to the garbage collector how much "pressure" they exert on a finite resource (file descr

Re: [go-nuts] What are finalizers missing?

I suggest you look at PhantomReference in Java, and the Cleaner/Disposer classes/patterns for how this would work. Go doesn't have PhantomReferences, so it's moot at this time.-Original Message- From: Tyler Compton Sent: Feb 14, 2020 1:09 PM To: golang-nuts Subject: [go-nuts] What are fin

[go-nuts] What are finalizers missing?

The conventional wisdom I see in the Go community is to avoid using finalizers to manage file descriptors, C memory, or any other non-Go memory resource. The generally accepted rationale (at least to my understanding) is that the garbage collector cannot be expected to run the finalizer promptly, a

Re: [go-nuts] Go without garbage collector

I'll be long dead - and also never made any claims that it wasn't possible - only that it hasn't happened.I will wager though that if there is such a thing a programming in 100 years, "developers" won't be doing manual memory management.-Original Message- From: ⚛ <0xe2.0x9a.0...@gmail.com>

Re: [go-nuts] Go without garbage collector

On Friday, February 14, 2020 at 6:46:51 PM UTC+1, Robert Engels wrote: > > Yes, and then the access and iteration is slower as it needs indirection > to find the correct page. There is no free lunch. > > The caveats about using mutable objects, sharing, and concurrency still > apply. > > A virtua

Re: [go-nuts] Go without garbage collector

Yes, and then the access and iteration is slower as it needs indirection to find the correct page. There is no free lunch.The caveats about using mutable objects, sharing, and concurrency still apply.A virtual machine environment has nothing to do with preventing direct memory access. You can do di

Re: [go-nuts] Go without garbage collector

On Friday, February 14, 2020 at 6:24:08 PM UTC+1, Robert Engels wrote: > > > Yes, and when you store value objects in a vector and it is resized, it is > very expensive as you need to make copies of "large objects", vs a "pointer > to an object". > A paged vector neither copies nor moves the obj

Re: [go-nuts] Go without garbage collector

Also, there are many other considerations - like if the objects are const, if not, using smart pointer refs may be the only way in a concurrent system, etc.There's a lot of factors to consider in value vs. reference - I trust the Googlers investigated which was most appropriate.-Original Messag

Re: [go-nuts] Go without garbage collector

Yes, and when you store value objects in a vector and it is resized, it is very expensive as you need to make copies of "large objects", vs a "pointer to an object".Which is better depends on the object lifetimes, size of objects, access patterns, etc.Clearly the Googlers that wrote the code felt t

Re: [go-nuts] Go without garbage collector

No, you do not. In C++ you would put object values in the vector, rather than pointers to objects. > On Feb 14, 2020, at 08:57, Robert Engels wrote: > > If you have a container of objects, you still need to free each object. If it > is an "container" of value objects (one reference to a block

Re: [go-nuts] Go without garbage collector

If you have a container of objects, you still need to free each object. If it is an "container" of value objects (one reference to a block of memory), you can free once at the block level, but if the block needs to be expanded (dynamic memory), you need to copy all of the data (or use a complex spa

Re: [go-nuts] Question about the zero-value design: Why pointers zero value is not the zero value of what they points to?

In addition, consider: how would you implement the zero default when the type is self-referential? For example: type Treenode struct { left *Treenode right *Treenode } var Tree1, Tree2 *Treenode Also consider deeply nested types which include pointers to structs which contain pointers etc

[go-nuts] JSON Encoding partial

I have a fairly complex struct that I'm using the mongo driver ( github.com/mongodb/mongo-go-driver) to create/maintain/manage schema inside mongodb. So the bson encoder (I have bson and json tags) works great on this same exact struct. I am now also trying to encode this same struct into JSON fo

Re: [go-nuts] How do you feel about using variadic functions for optional dependency injection in Go?

This reminds me of the "functional options" approach: https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis Of course, the difference being Dave is talking about configuring a struct type and you're talking about configuring a func type. -- You received this message because you

Re: [go-nuts] Question about the zero-value design: Why pointers zero value is not the zero value of what they points to?

On Fri, Feb 14, 2020, at 09:16, kloste...@gmail.com wrote: > *Could you please let me know the reasons why the zero value of a > pointer is `nil` instead of a pointer to the zero value of what it > points to?* > > Is it because of performance/memory? Simplicity in the runtime? The zero value is a

Re: [go-nuts] Go without garbage collector

On Thu, Feb 13, 2020 at 7:48 PM Alex Besogonov wrote: > And no, reference counting is NOT a GC. > > General consensus, at least among academia, is that automated reference counting is a GC scheme. You may argue that it is not based on whether it is implicitly done (Like Ruby and Python did/does),

Re: [go-nuts] Go without garbage collector

On Friday, February 14, 2020 at 3:43:40 PM UTC+1, Robert Engels wrote: > > If each object exists independently - which it does in this case - you > must use a free on each object. So you are going to loop - it just may be > hidden from you. > I am sorry, I do not understand your style of reasoni

Re: [go-nuts] Go without garbage collector

If each object exists independently - which it does in this case - you must use a free on each object. So you are going to loop - it just may be hidden from you. The idea was to avoid all free calls and terminate the process instead - which I pointed out has been a solution for quite a long ti

Re: [go-nuts] Reading data from a small number of files in parallel

You cannot use a pool of File if rotated means close, rename , reopen. A File is a user space representation of an inode so rotating means the File still points to the original file (beware on Windows). A file open / reopen is really cheap on recent files in a modern os. If the real issue you

Re: [go-nuts] Go without garbage collector

On Friday, February 14, 2020 at 3:32:54 AM UTC+1, robert engels wrote: > > You can clearly see that the vast majority of CPU time was consumed by > allocation and de-allocation. > In the case of this particular benchmark, it is pointless to be pointing out the cost of individual malloc+free call

[go-nuts] How do you feel about using variadic functions for optional dependency injection in Go?

Example: https://play.golang.org/p/DmAN1Kxi7VD So I started growing fond of a new pattern in my Go code. Not sure if it is an antipattern for go or not but here is a quick description to see what everyone thinks: In order to properly unit test a lot of code, sometimes you have to decouple som

[go-nuts] Question about the zero-value design: Why pointers zero value is not the zero value of what they points to?

This is a question to get some information before thinking about a possible proposal regarding zero values. *Could you please let me know the reasons why the zero value of a pointer is `nil` instead of a pointer to the zero value of what it points to?* Is it because of performance/memory? Simpl

[go-nuts] Reading data from a small number of files in parallel

Hi everyone, I am building a system where we store data (text) in a file for a day and at the end of the day the file is rotated. For each data, one single file contains the data for that file. I was wondering what would be the best way to read from the file, opening the file for reading each ti

Re: [go-nuts] cmd/vet: "possible misuse of unsafe.Pointer" on C pointer -> uintptr -> different package -> unsafe.Pointer -> C pointer

wow ... that just seems so obvious now. Thanks! On Friday, 14 February 2020 12:41:48 UTC+8, Ian Lance Taylor wrote: > > On Thu, Feb 13, 2020 at 8:42 AM Alex > > wrote: > > > > I have to pass C pointers between packages so I used uintptr like how > syscall does things. > > However go vet gives