for example A deps B and B deps C
adds replace B => local/path/to/B in A/go.mod and replace C =>
local/path/to/C in B/go.mod
changes C doesn't rebuilds A.
it's it a bug or work as intend?
how could i make rebuild works, otherwise i may need to create git commits,
update A and B package again a
Round(0) ensures that the expiry is being compared to the wall clock time,
since that's what the server uses to verify.
If you're interested, you can look at https://golang.org/cl/83575, the commit
that introduced this logic.
--
You received this message because you are subscribed to the Googl
pprof is not only cpu profiling - it is the same tracing infrastructure used in
the go analyzer.
> On Apr 22, 2020, at 2:28 PM, David Finkel wrote:
>
>
>
>
>> On Mon, Apr 20, 2020 at 8:35 PM asaxena via golang-nuts
>> wrote:
>> Hi,
>>
>> I am trying CPU profiling a program that runs for
But it’s a data race regardless. Even if the runtime did interrupt the go
routine mid write and change the stack it would be forced to eventually correct
the value to have the write be valid - but if another routine is reading that
value, including the GC, there must be synchronization added. In
On Wed, Apr 22, 2020 at 7:08 AM T L wrote:
>
> I understand that, by the case 6 in the unsafe package docs,
> the second program should be safe with or without the runtime.KeepAlive call.
> I just wonder how Go runtime achieves this goal.
> I have an impression that pointer assignments in Go by gc
On Wed, Apr 22, 2020 at 4:33 AM T L wrote:
>
> On Tuesday, April 21, 2020 at 8:13:17 PM UTC-4, Ian Lance Taylor wrote:
>>
>> On Tue, Apr 21, 2020 at 8:17 AM T L wrote:
>> >
>> > And is the runtime.KeepAlive call in the following program essential to
>> > keep the correctness?
>> >
>> > package m
On Mon, Apr 20, 2020 at 8:35 PM asaxena via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> Hi,
>
> I am trying CPU profiling a program that runs for an hour. However when I
> start pprof it says Total samples are only for 1.32 min. Why are the
> samples not collected for the whole duration o
On Wed, Apr 22, 2020 at 9:40 AM Sid Sid wrote:
>
> Thanks for your detailed answers!
> Mr. Than, can you also shed some light on the calling conventions (CC)?
> I got the impression CC might be a serious obstacle for some projects using
> LLVM as backend (Mono, llilc).
> What is situation with go
Hi,
This doesn't answer your question but usually when I need to profile our
app, I first use expvar to report different internal stats like what the
app is doing (how many records is it walking from the db, any batch
process, etc), send those to datadog (any monitoring works fine) and then I
Anyone looking for a team to build something?
--
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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on
Thanks for your detailed answers!
Mr. Than, can you also shed some light on the calling conventions (CC)?
I got the impression CC might be a serious obstacle for some projects using
LLVM as backend (Mono, llilc).
What is situation with go-CC in gollvm? Is it easy to use standart llvm
solutions fo
Hi,
Thanks for your note.
The big picture is that gollvm is still very much an experimental version
of Go; we take care of it and keep it operating at a basic level, but it
can be unstable at times. Worth adding that development activity on Gollvm
is mostly paused at the moment while Cherry and I
I understand that, by the case 6 in the unsafe package docs,
the second program should be safe with or without the runtime.KeepAlive
call.
I just wonder how Go runtime achieves this goal.
I have an impression that pointer assignments in Go by gc is atomically,
but is this also true for uintptr val
On Tuesday, April 21, 2020 at 8:13:17 PM UTC-4, Ian Lance Taylor wrote:
>
> On Tue, Apr 21, 2020 at 8:17 AM T L >
> wrote:
> >
> > And is the runtime.KeepAlive call in the following program essential to
> keep the correctness?
> >
> > package main
> >
> > import (
> > "fmt"
> >
2020. április 22., szerda 10:04:37 UTC+2 időpontban Pavan a következőt írta:
>
>
> Hi,
> putting the lockosthread from library cant match with goroutines TLS and
> its complex on handling goroutines exit and mapping all the GO api's (C
> fns if any with them ) called by applications to same O
On Tue, 21 Apr 2020 02:22:37 -0700 (PDT)
Rakesh K R wrote:
> In C, we used to typecast this array of uint8_t to predefined
> structure.
>
This is very bad even for a C program, as soon as you dereference
pointer to such structure it's an undefined behavior, and not portable
even on LE architect
Hi,
putting the lockosthread from library cant match with goroutines TLS and
its complex on handling goroutines exit and mapping all the GO api's (C
fns if any with them ) called by applications to same OS thread .
ofcourse applications cant call lockosthread too as they are not aware of
t
Thanks Tamas , I see earlier discussion too on this
https://groups.google.com/forum/#!topic/golang-nuts/8Tdb-aCeYFY.
As I understand, the GO library should lock the current go routine to
thread, if it involves C functions with TLS data and unlock after
completing such C functions .
Regards,
18 matches
Mail list logo
