Apologies, the cover tool calls it -mode but the go command calls it
-covermode.
go test -covermode=atomic
-rob
On Sun, Oct 2, 2022 at 3:48 PM Shulhan wrote:
> On Sun, 2 Oct 2022 10:41:17 +1100
> Rob Pike wrote:
>
> > When running coverage in a concurrent program, use the -mode=atomic
> > fl
Also, it is documented:
% go help testflag | grep mode
-covermode set,count,atomic
Set the mode for coverage analysis for the package[s]
When 'go test' runs in package list mode, 'go test' caches successful
%
On Sun, Oct 2, 2022 at 7:22 PM Rob Pike wrote:
> Apologies, the cover tool cal
On Sun, 2 Oct 2022 19:22:21 +1100
Rob Pike wrote:
> Apologies, the cover tool calls it -mode but the go command calls it
> -covermode.
>
> go test -covermode=atomic
>
> -rob
>
>
Got it, thanks, but it still fail with the data race.
(ins) 1 $ GOEXPERIMENT=coverageredesign CGO_ENABLED=1
This is a race in new code, then, so please file an issue at
https://go.dev/issue/new
-rob
On Sun, Oct 2, 2022 at 7:40 PM Shulhan wrote:
>
> On Sun, 2 Oct 2022 19:22:21 +1100
> Rob Pike wrote:
>
> > Apologies, the cover tool calls it -mode but the go command calls it
> > -covermode.
> >
> > go
On Sun, Oct 2, 2022 at 1:37 AM Robert Engels wrote:
> I don’t see any arguments refuting the claim? Can you include a link so the
> analysis can be read in context?
The word "coroutines" does not ring a bell?
--
You received this message because you are subscribed to the Google Groups
"golan
Not an entirely true statement, and a fairly misunderstanding of the
subject.
On Saturday, October 1, 2022 at 11:13:19 PM UTC+2 al...@pbrane.org wrote:
> Robert Engels once said:
> > I think you’ll find the article interesting. It is certainly written
> > by a CS “god” that knows what he’s ta
By many definitions Go routines and virtual threads are technically coroutines
- versus a platform/OS thread.
Again, I would like a link to the source of statement to evaluate it in
context.
> On Oct 2, 2022, at 5:32 AM, w54n wrote:
>
> Not an entirely true statement, and a fairly misunder
Also, until fairly recently Go routines were non preemptive- making them even
closer to a coroutine. I have no idea when this statement was made to judge
that aspect as well.
> On Oct 2, 2022, at 6:15 AM, Robert Engels wrote:
>
>
> By many definitions Go routines and virtual threads are tec
On Sun, 2022-10-02 at 06:15 -0500, Robert Engels wrote:
> Again, I would like a link to the source of statement to evaluate it
> in context.
https://manningbooks.medium.com/interview-with-brian-goetz-7d6c47d05d63
--
You received this message because you are subscribed to the Google Groups
"gol
On Sun, Oct 2, 2022 at 1:16 PM Robert Engels wrote:
> By many definitions Go routines and virtual threads are technically
> coroutines - versus a platform/OS thread.
Show one please.
Coroutines are normally a subject of non-preemptive multitasking,
threads are normally just the opposite. [0]
Thank you. Great interview. As expected, everything he said was true -
especially when you read the full segment - one in about 50 presented. No
wonder the original poster did not want to link to the full article. I’ll
reiterate - “CS god”.
I did a quick review of k8s - and it is almost equal
On Sun, Oct 2, 2022 at 2:47 PM Robert Engels wrote:
> I already pointed that out.Go routines were non preemptive until recently.
> They are also still non preemptive when calling a system call without direct
> support, or CGo - it spins up another platform thread.
I'm talking about a principal
On Sun, Oct 2, 2022 at 3:04 PM Robert Engels wrote:
> One other thing, if you don’t think he knows exactly how Go routines are
> implemented you are delusional.
Maybe he should then fix the Wikipedia article I linked before. Good
luck with that.
PS: I assume you meant "goroutines" instead of "
On Sun, Oct 2, 2022 at 3:00 PM Robert Engels wrote:
> They are still non-preemptive. Even the way preemption is implemented is
> cooperative.
Goroutines are preempted in a thread signal handler that invokes the
Go runtime scheduler that in turn saves the required goroutine state
and switches th
Can we collectively stay calm and within the bounds of polite discourse?
The overall tone of this thread is pretty aggressive.
I would also like to point out that this particular topic of discussion -
the credentials of the author of the original article - seem fallacious to
me from either side. T
For various reasons we need to patch cryptobytes for our build
(https://github.com/evcc-io/eebus/issues/1#issuecomment-1146843187).
We've tried to do this in a consistent way for local, Docker and Github CI
build by vendoring our modules (go mod vendor) and patching the vendored
copy. Test con
https://go.dev/play/p/gIVVLsiTqod
I'm trying to understand concurrency, so I modified a small routine I came
across quite a while ago. It's a grep command, but since I have its
source, I am trying to understand its concurrency.
My problem is that when there are more than about 1800 files to be
On Sun, Oct 2, 2022 at 7:36 PM Robert Solomon wrote:
> https://go.dev/play/p/gIVVLsiTqod
I believe wg.Add on line 125 is too late. I think it needs to be moved
before the go statement on line 108. Not tested.
--
You received this message because you are subscribed to the Google Groups
"golang
First reason I notice, if there's an error opening your file, wg.Done() is
never called.
On Sun, Oct 2, 2022, 1:36 PM Robert Solomon wrote:
> https://go.dev/play/p/gIVVLsiTqod
>
> I'm trying to understand concurrency, so I modified a small routine I came
> across quite a while ago. It's a grep
When I do that, I get this error:
panic: sync: negative WaitGroup number
On 10/2/22 14:39, Jan Mercl wrote:
On Sun, Oct 2, 2022 at 7:36 PM Robert Solomon wrote:
https://go.dev/play/p/gIVVLsiTqod
I believe wg.Add on line 125 is too late. I think it needs to be moved
before the go statement
I think Matthew is correct about the immediate source of the deadlock -
because the defer is placed too late in the body of grepFile(), the
deferred decrement of the waitGroup isn't run on an os.Open() error.
I had the same impression as Jan, I think there is a concern here: the
condition for c
Looks like you're right.
I changed the order of the defer statement and now I'm not getting that
error.
Interesting that I never saw any file errors.
Thanks
--rob solomon
On 10/2/22 14:46, Matthew Zimmerman wrote:
First reason I notice, if there's an error opening your file,
wg.Done() is
Ian Lance Taylor schrieb am Sa. 1. Okt. 2022 um 17:12:
>
> Another example of goroutine-local storage that we currently support
> is runtime/pprof.Do, which adds labels to the current goroutine. This
> seems OK as the labels are readonly and are inherited by goroutines
> started with a go statem
On Mon, 2022-10-03 at 00:46 +0200, Sven Anderson wrote:
> As it happens, I wrote a small package, that does that „almost“
> legally:
> https://pkg.go.dev/github.com/ansiwen/gctx
There is also github.com/kortschak/goroutine for getting goroutine IDs,
which can be used as the primitive for construc
On Sun, Oct 2, 2022, 4:46 PM Sven Anderson wrote:
> Ian Lance Taylor schrieb am Sa. 1. Okt. 2022 um 17:12:
>
>>
>> Another example of goroutine-local storage that we currently support
>> is runtime/pprof.Do, which adds labels to the current goroutine. This
>> seems OK as the labels are readonly
I don't know how to change that.
I had an issue w/ the main routine ending before some of the worker
routines were done so I saw incomplete results.
How do I tweak my logic so that I don't need a WaitGroup?
I forgot about my platform specific code. Here is the rest of that, that
is in a fil
how to profiling for post method for rest api in golang
On Thursday, January 14, 2016 at 7:26:42 PM UTC+5:30 Tamás Gulácsi wrote:
> You can try https://github.com/rakyll/gom which is almost that: a
> continuous pprof. Maybe some persistence shall be added to gom.
--
You received this message
Hi Chris,
I'm one of the CLP developers. We'd be interested in hearing your use case
and any features you'd like implemented in CLP.
As for a Go implementation, are you asking about bindings to directly call
CLP functionality from a Go program or are you interested in a complete
re-write in Go?
I’m on arm64 Darwin and wanted to view the asm output for amd64 Darwin.
Using a simple hello world example, this worked and output arm asm:
$ go tool compile -S hello.go
This worked and built a full x86 binary:
$ GOARCH=amd64 go build hello.go
But this failed:
$ GOARCH=amd64 go tool compile -
On Sun, Oct 2, 2022 at 6:45 PM Eli Lindsey wrote:
>
> I’m on arm64 Darwin and wanted to view the asm output for amd64 Darwin.
>
> Using a simple hello world example, this worked and output arm asm:
>
> $ go tool compile -S hello.go
>
> This worked and built a full x86 binary:
>
> $ GOARCH=amd64 go
On Sun, Oct 2, 2022 at 8:45 AM cpu...@gmail.com wrote:
>
> For various reasons we need to patch cryptobytes for our build
> (https://github.com/evcc-io/eebus/issues/1#issuecomment-1146843187).
>
> We've tried to do this in a consistent way for local, Docker and Github CI
> build by vendoring our
Thanks! CLP is great!
I am working on a distributed file system, SeaweedFS,
https://github.com/seaweedfs/seaweedfs
I am interested in a pure-go implementation to store the log files more
efficiently.
Chris
On Sun, Oct 2, 2022 at 6:45 PM david lion wrote:
> Hi Chris,
>
> I'm one of the CLP deve
On Sun, 2 Oct 2022 20:45:08 +1100
Rob Pike wrote:
> This is a race in new code, then, so please file an issue at
> https://go.dev/issue/new
>
> -rob
>
Done, https://github.com/golang/go/issues/56006
Thank you for walking me through this.
--
You received this message because you are subscrib
I've tried to come to grips with the lovingly detailed
https://pkg.go.dev/os/signal preamble, but I'm going to ask to get the
experts thoughts. On Linux, my scenario is:
I have a main program main.go. Via CGO, it loads libmyc.so, a large,
legacy, C .so shared library. Obviously the executable
34 matches
Mail list logo
