On Tue, Jun 22, 2021 at 1:23 AM Steven Penny wrote:
> OK, so all all these decades of experience, why cant anyone produce a small
> program to demonstrate the problem?
I must say, I'm impressed by Dan taking the time to actually provide one.
My answer to this would have been: Because we would
On Mon, 2021-06-21 at 18:22 -0500, Steven Penny wrote:
> I am not questioning anyones knowledge, I am just asking for a
> demonstration, rather than "do it because we said so".
https://play.golang.org/p/gwDnxVSQEM4
--
You received this message because you are subscribed to the Google Groups
"g
Thanks to all the replies, but looks like I got the answer from
another forum [1]. Copying here:
The Close() method was originally used to tear down the background
groutine used by the deflater. The background goroutine was removed
in in a June, 2011 change list [2]. The author of the CL wrote th
On Mon, Jun 21, 2021 at 4:23 PM Steven Penny wrote:
>
> > You asked a question. People here are genuinely trying to help you by
> > giving you their acquired knowledge of (collectively) over more than a
> > couple of decades of Go programming.
>
> OK, so all all these decades of experience, why ca
On Mon, Jun 21, 2021 at 4:23 PM Steven Penny wrote:
> > You asked a question. People here are genuinely trying to help you by
> > giving you their acquired knowledge of (collectively) over more than a
> > couple of decades of Go programming.
>
> OK, so all all these decades of experience, why can
But it is not "because we said so". There were actual replies that pointed
to specific issues that, in my opinion, were reason enough. To create a
specific test case that would break (assuming there is not such a test in
the standard library already. Worth checking) it would take some time for
some
> You asked a question. People here are genuinely trying to help you by
> giving you their acquired knowledge of (collectively) over more than a
> couple of decades of Go programming.
OK, so all all these decades of experience, why cant anyone produce a small
program to demonstrate the problem? Ei
On Mon, 2021-06-21 at 17:57 -0500, Steven Penny wrote:
> > No, I gave a clear path that would lead to a case of a non-detected
> > error when Close is not called.
> >
> > This seems like a really odd hill to die on, but it's your choice I
> > guess.
>
> You calling "go look through 3200 lines of Go
Internally close calls z.decompressor.Close() where decompressor is
typically obtained via flat.NewReader(r) which states
NewReader returns a new ReadCloser that can be used to read the
uncompressed version of r. If r does not also implement io.ByteReader, the
decompressor may read more data than
> No, I gave a clear path that would lead to a case of a non-detected
> error when Close is not called.
>
> This seems like a really odd hill to die on, but it's your choice I
> guess.
You calling "go look through 3200 lines of Go code" (not including tests) [1] a
"clear path" is a dubious comment
On Mon, 2021-06-21 at 17:44 -0500, Steven Penny wrote:
> and none has been able to provide a simple program that demonstrate a
> problem that could arise from not closing gzip reader.
No, I gave a clear path that would lead to a case of a non-detected
error when Close is not called.
This seems li
>> - https://golang.org/pkg/compress/flate
>>
>> - https://golang.org/pkg/compress/lzw
>> - https://golang.org/pkg/compress/zlib
>
> All of these do.
whoops, yeah thats true. However my original point still stands. Three people
have replied now:
- Axel Wagner
- Bruno Albuquerque
- Dan Kortschak
On Mon, 2021-06-21 at 17:30 -0500, Steven Penny wrote:
> > No other compress reader even has a Close method, so I think Im
> > fine:
>
> - https://golang.org/pkg/compress/bzip2
> - https://golang.org/pkg/compress/flate
> - https://golang.org/pkg/compress/lzw
> - https://golang.org/pkg/compress/zlib
On Tue, Jun 22, 2021 at 12:31 AM Steven Penny wrote:
> No other compress reader even has a Close method, so I think Im fine:
>
> - https://golang.org/pkg/compress/bzip2
This one hasn't.
>
> - https://golang.org/pkg/compress/flate
- https://golang.org/pkg/compress/lzw
> - https://golang.org/p
Dan just pointed out that the Close() method for the gzip reader actually
does other things. If you are ok with not detecting a possible error with
deferred reporting through the Close() method then, yes, you are ok. I see
no good reason why you would though.
On Mon, Jun 21, 2021 at 3:30 PM Steve
On Mon, Jun 21, 2021 at 11:53 PM Steven Penny wrote:
> Thanks for the responses, but I am not convinced. Other than "its just good
> practice", I havent seen a single concrete example where not closing a gzip
> reader would cause a problem.
This is what we call a black swan fallacy.
> Until t
> Not to mention this all is an implementation detail and even if it did
> nothing today, relying on this behavior would be a recipe so see cobe
> breaking in the future. In this sense, the advice "if there is a Close()
> method, call it when you are done with it" is a very good one.
No other comp
Not to mention this all is an implementation detail and even if it did
nothing today, relying on this behavior would be a recipe so see cobe
breaking in the future. In this sense, the advice "if there is a Close()
method, call it when you are done with it" is a very good one.
On Mon, Jun 21, 2021
On Mon, 2021-06-21 at 16:53 -0500, Steven Penny wrote:
> > Again, the idiom is, if you get an `io.Closer`, `Close` should be
> > called once
> > you're done with it.
>
> Thanks for the responses, but I am not convinced. Other than "its
> just good
> practice", I havent seen a single concrete exampl
> Again, the idiom is, if you get an `io.Closer`, `Close` should be called once
> you're done with it.
Thanks for the responses, but I am not convinced. Other than "its just good
practice", I havent seen a single concrete example where not closing a gzip
reader would cause a problem. Until that ha
To be clear, I said "things I could imagine". But:
On Mon, Jun 21, 2021 at 11:28 PM Steven Penny wrote:
> Thanks for the response. Couple of points:
>
> > 1. You don't get notified about checksum mismatches or the like. i.e. the
> > data you read might be corrupted and you might not realize it.
Thanks for the response. Couple of points:
> 1. You don't get notified about checksum mismatches or the like. i.e. the
> data you read might be corrupted and you might not realize it.
I dont think this is true. I tried with this file [1], and Close returns the
same error as, for example io.Copy,
There are two potential negative consequences I could imagine happening:
1. You don't get notified about checksum mismatches or the like. i.e. the
data you read might be corrupted and you might not realize it.
2. There might, theoretically, be goroutines spawned which get leaked if
you don't `Close
If I have a program like this, it fails as expected (on Windows):
~~~
package main
import (
"fmt"
"os"
)
func main() {
old := "go1.16.5.src.tar.gz"
os.Open(old)
err := os.Rename(old, "new.tar.gz")
// The process cannot access the file because it is being used by
another proces
How many processes per machine? It seems like scheduling latency to me.
> On Jun 21, 2021, at 6:31 AM, Peter Z wrote:
>
>
>> So, you have about 500,000 processes running this agent on each machine, and
>> each process has around 7,000 gorouines? Is that correct?
>
> Yes, that's exactly wha
How do the heap sizes output by gctrace map to the various values of
MemStats? I assume that the heap values from gctrace roughly match *one* (or
two?) of the MemStats fields, but I can't find anything that documents that.
I see in the code that the gctrace outputs are mostly based
on heap_li
Thanks all for your support.
As workaround, I buffer the response until I read completely the request.
In order to limit the GC and consumption of resource, I recycle the the
bytes.Buffer with sync.Pool that is in charge of create bytes.Buffer with
initial capacity.
Le samedi 19 juin 2021 à 12:1
>
> So, you have about 500,000 *processes *running this agent on each
> machine, and each process has around 7,000 gorouines? Is that correct?
>
Yes, that's exactly what I mean.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe
Ah, OK, thanks.
Would be great if the documentation showed what OS/ARCH one was browsing.
I didn't know about this functionallity, but very useful!
On Friday, June 18, 2021 at 11:34:55 p.m. UTC+2 axel.wa...@googlemail.com
wrote:
> I guess you have to specify GOOS/GOARCH to a combination that act
Could you clarify something? You say:
" We have about half a million agents running on each of our machines"
in your initial message. I thought maybe it was a language thing, and you
meant 500,000 goroutines. But then you said:
"There are 7000 goroutines total"
So, you have about 500,000 *process
Hi everyone,
In the absence of an answer, I reply here to make this thread go back to
top.
For the moment I have worked around my issue by just adding a subdirectory
in gest/ (see hierarchy above), and *//go:generate*'ing on this package.
This works here because this sub-package does not impor
Thanks for that axel. I had tried "./" and "/". I guess I missed one :)
On Sunday, June 20, 2021 at 11:53:03 PM UTC-7 axel.wa...@googlemail.com
wrote:
> You need to pass "." to `fs.WalkDir`, not "".
>
> On Mon, Jun 21, 2021 at 7:42 AM John wrote:
>
>> package main
>>
>> import (
>> "embed"
>>
32 matches
Mail list logo
