On Mon, Apr 26, 2021 at 8:57 PM Pure White <wu.purewh...@gmail.com> wrote: > > As you have said, the cost of making the cgo call is too expensive for my > situation. > > I know using go:linkname to call systemstack is magic and neither recommended > nor supported. But I don’t have other choice. > > My application will call `time.Now` very often to get the timestamp, so this > optimization is useful for me. > > Put this aside, I think go should provide a way to do all the thing I need > outside runtime. Maybe exporting something like `runtime.systemstack` sounds > reasonable for me as there may be some need to call func on a large stack > such as g0 stack. What do you think?
runtime.systemstack is a runtime-internal function. It does not make sense to expose it. The kind of code that can run on the system stack is quite limited. It's true that making a non-blocking system call is the kind of code that is OK, but most code would lead directly to a program crash. It's not Go style to give programs fragile and dangerous mechanisms like that. I really encourage you to explain in detail what you are doing, if you can. That may help lead people to finding a solution that can work. The position right now is that your program must call clock_gettime(CLOCK_REALTIME_COARSE) without using cgo. As far as I can tell that is impossible today, though of course it could be added to future releases of Go. But first let's find out whether that is in fact the right solution. Ian > 在 2021年4月27日 +0800 AM6:39,Ian Lance Taylor <i...@golang.org>,写道: > > On Mon, Apr 26, 2021 at 1:24 AM Pure White <wu.purewh...@gmail.com> wrote: > > > I'm trying to get time using `CLOCK_REALTIME_COARSE` and > `CLOCK_MONOTONIC_COARSE` for performance reasons, and need to use vdso call > by hand-written assembly code. That is, I want to reimplement `time.Now` > using `CLOCK_REALTIME_COARSE` and `CLOCK_MONOTONIC_COARSE`. > > I referenced the code in runtime and found that there's an issue #20427 > indicates that I need to switch to g0 for vdso calls, so I tried two methods > but neither is good. > > ## The first method > > The first method I tried is just copy the code in runtime and simply change > the clockid, but this requires copying all the runtime type definations as > well to make the compiler generate "go_asm.h" for me. > > The code runs well, but this is really ugly and unmaintainable as the type > definations may change across different go versions. > > ## The second method > > The second method I tried is to link the `runtime.systemstack` and use it to > do vdso calls: > ```go > //go:linkname systemstack runtime.systemstack > //go:noescape > func systemstack(fn func()) > ``` > > My code is something like this: > > ```go > // now calls vdso and is implemented in asm > func now() (sec int64, nsec int32, mono int64) > > func Now() { > var sec, mono int64 > var nsec int32 > systemstack(func() { > sec, nsec, mono = now() > }) > ... // logic copied from time.Now() > } > ``` > > The code runs well without `-race`(test isn't enough), but I encountered > fatal error under `-race` mode. > For detailed information, I've filed an issue: > https://github.com/golang/go/issues/45768. > > ## The right way? > > So I really want to know what is the right way to do vdso call outside > runtime? > > > The right way is to use cgo. But probably the cost of making the cgo > call will overwhelm the speed advantage of using the coarse clocks. > > Using go:linkname to call systemstack is completely unsupported, and > is even less maintainable than your first method. > > I have to admit that I don't see a way to do this at all. What is the > application? How much difference will it make to use the coarse > timestamps? > > Ian -- 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 the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVR%2BPxKZhkm%2B0f8MUsxP6WB08Y_MzFAZPkihBpvWEoh%2Bg%40mail.gmail.com.