This might be trivial, but could you explain me the relationship between the following? 1. value returned by __tls_get_addr 2. runtime.g 3. runtime.g0 4. runtime.mo 5. runtime.m
Thanks:) On Thursday, September 10, 2020 at 11:31:21 AM UTC+9 Ian Lance Taylor wrote: > On Wed, Sep 9, 2020 at 7:26 PM Yonatan Gizachew <eme...@gmail.com> wrote: > > > > Is there any known problems that could appear when we run golang > C-shared libraries in an OS that uses a non-preemptive scheduling > mechanism. I am experiencing some problems related to TLS (more > specifically runtime.m0 and runtime.g0). > > FYI - the C-shared library was built suing the gccgo compiler as: > > go build -o libgotest.so -buildmode=c-shared -compiler=gccgo test.go > > Note that runtime.m0 and runtime.g0 are not themselves TLS variables. > runtime.g is a TLS variable. > > As gccgo has not been tested on your platform, any number of problems > are possible. How does your OS handle scheduling non-preemptively? > Only schedule on system calls? I think that could work with typical > Go programs, although it could longer GC pauses with gccgo. > > 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/d17f2ac0-d311-4eb1-b301-2d92fd6a4140n%40googlegroups.com.
