I build gollvm on linux. Is gollvm depend on a fiexed version of llvm?
what's the version? thx
-- Retry after 5 seconds (attempt #3) ...
/home/zyq/strength/gollvm/workarea/llvm-project/llvm/tools/gollvm/passes/GC.cpp:47:3:
错误：‘Optional’不是一个类型名
47 | Optional isGCManagedPointer(const Type *T
Thanks for the comments. I had to do it as root because running
go install -buildmode=shared std
as me results in
go install internal/goarch: mkdir /usr/local/go/pkg/linux_amd64_dynlink:
permission denied
As root, changing the ownership of /usr/local/go/pkg/linux_amd64_dynlink to
me, and then
On Mon, Jan 30, 2023 at 4:42 PM Robert Engels wrote:
>
> Yes but only for a single reader - any concurrent reader is going to
> park/deschedule.
If we are talking specifically about Go, then it's more complex than
that. In particular, the code will spin briefly trying to acquire the
mutex, befo
Looking back at your posts, I think you got there because your initial
build of the shared library was via sudo? I don’t think that was correct
and you didn’t need sudo.
If the shared library only contained code needed for your executable, then
it could only be shared by other instances of your ex
Yes but only for a single reader - any concurrent reader is going to
park/deschedule.
There’s a reason RW locks exist - and I think it is pretty common - but agree
to disagree :)
> On Jan 30, 2023, at 6:23 PM, Ian Lance Taylor wrote:
>
> On Mon, Jan 30, 2023 at 1:00 PM Robert Engels wrote:
On Mon, Jan 30, 2023 at 1:00 PM Robert Engels wrote:
>
> Pure readers do not need any mutex on the fast path. It is an atomic CAS -
> which is faster than a mutex as it allows concurrent readers. On the slow
> path - fairness with a waiting or active writer - it degenerates in
> performance to
A quick search found this https://yizhang82.dev/lock-free-rw-lock which
describes the algo pretty well.
> On Jan 30, 2023, at 3:00 PM, Robert Engels wrote:
>
> Pure readers do not need any mutex on the fast path. It is an atomic CAS -
> which is faster than a mutex as it allows concurrent re
Pure readers do not need any mutex on the fast path. It is an atomic CAS -
which is faster than a mutex as it allows concurrent readers. On the slow path
- fairness with a waiting or active writer - it degenerates in performance to a
simple mutex.
The issue with a mutex is that you need to acq
I'm the original poster. I've looked into this more and I might have an
explanation for
what's going on.
Just for yuks, I started with perhaps the simplest Go program, which I
called t.go:
package main
func main() {
}
As root, I was able to build both a dynamically (21512 bytes) and a
statica
On Mon, Jan 30, 2023 at 11:26 AM Robert Engels wrote:
>
> I don’t think that is true. A RW lock is always better when the reader
> activity is far greater than the writer - simply because in a good
> implementation the read lock can be acquired without blocking/scheduling
> activity.
The best
This seems to be related to https://github.com/golang/go/issues/31222
does runtime.mallocgc blocks the pre-emption in go1.18 ? We see long sweep
termination phase. Allocation size is 32K - 64K.
Trace Image Link:
https://github.com/NeetishPathak/GolangDebug/blob/main/gc_pause.png
On Tuesday,
I don’t think that is true. A RW lock is always better when the reader activity
is far greater than the writer - simply because in a good implementation the
read lock can be acquired without blocking/scheduling activity.
> On Jan 30, 2023, at 12:49 PM, Ian Lance Taylor wrote:
>
> On Sun, Jan
On Sun, Jan 29, 2023 at 6:34 PM Diego Augusto Molina
wrote:
>
> From times to times I write a scraper or some other tool that would
> authenticate to a service and then use the auth result to do stuff
> concurrently. But when auth expires, I need to synchronize all my goroutines
> and have a si
How does the community maintain fuzz test cases? Is there a CI project or
pipeline？Although run.bash executes the fuzz test case, there is no random
input.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop
On 1/29/23, bobj...@gmail.com wrote:
> I'm glad to see this issue getting some discussion. I have 100+ smallish
> utility programs written in Go, and each one consumes about 1.5 MB (precise
>
> average: 1,867,844 bytes); my bin directory contains 100+ copies of the Go
> runtime. Sadly, I mainly us
Here are some more options you could consider.
1. Do what busybox does: put them all into separate packages, link them all
into one monster executable, switching on os.Args[0] to decide which main
function to run. Then add lots of links or symlinks to the same program so
it can be executed und
16 matches
Mail list logo
