On Fri, Sep 28, 2018 at 7:45 AM, changkun <euryugas...@gmail.com> wrote: > > On Friday, September 28, 2018 at 4:12:31 PM UTC+2, Ian Lance Taylor wrote: >> >> On Fri, Sep 28, 2018 at 7:08 AM, changkun <euryu...@gmail.com> wrote: >> > >> > 1. Is my suspicion reasonable and correct? >> >> I wouldn't be my first guess. You say that pango memory is >> per-thread. That suggests that you need to always call pango on a >> consistent thread. > > > Not really, the original C code calls pango in every new created thread. > > After involving cgo, it doesn’t change anything of this calling behavior.
Right, but what changes using cgo is that consecutive calls using the same pango objects will be on different threads. That likely does not happen in the original C code. >> That will not happen by default. You likely need >> to arrange to make all your pango calls from a single goroutine, and >> have that goroutine first call runtime.LockOSThread. > > > Tried, it doesn’t work. A goroutine is created for the cgo call purpose, > which instantly entering C side, when C code creates a thread, > then call pango inside that thread. OK, sounds like I was wrong. But I don't understand what it means for pango to have per-thread data structures if you always make pango calls in a newly created thread. >> > 2. Why an error when involving cgo? >> >> My first guess would be that it is because you are calling the cgo >> code from different threads. > > > Nope. It is all about from Go to C then C doing something > without sending data back to Go. I am not calling Go from C. No, I didn't think you were. >> > 3. Are memories in a non-Go thread completely isolated to Go >> > memory per-non-Go thread? >> >> Sorry, I don't understand this question. >> > > I was trying to express that, are memories in every non-Go thread > are isolated one another? > > The warning from pango: > > (process:1): GLib-GObject-WARNING **: cannot register existing type > 'PangoFontMap' > > Looks like that the pango call is double registering the font map object. > If the memory are shared across all non-Go thread, it cloud be an issue, > isn’t it? All threads in both C and Go share the same memory space. But, obviously, they do not share the same per-thread data structures. 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. For more options, visit https://groups.google.com/d/optout.
