On Friday, September 28, 2018 at 6:44:10 PM UTC+2, Ian Lance Taylor wrote: > > On Fri, Sep 28, 2018 at 7:45 AM, changkun <euryu...@gmail.com > <javascript:>> 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. >
Yep. I understand that goroutines run in different threads. They seem not able to influence the entire 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. > That is actually the most wired part. Indeed, the Pango call is always called in a newly created thread. So my concern is somehow someway, cgo or Go influences the memory layout, then probably caused the "double variable registering" of pango underlying call to glib? > > > >> > 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. > > > > > 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. > Perhaps, to understand where the problem comes from, the only way is to read what actually the call is doing, g_private_get() and pango_cairo_font_map_new() in GLib and Pango correspondingly. https://github.com/GNOME/pango/blob/2bb6262be19dc17f7b56d3ce36c0defdbdb55c97/pango/pangocairo-fontmap.c#L184 However, I rather say, GTKs are extremely stable for years, consider the problem arise when involving Go and cgo, and I do not change any of the C part, it is most likely the Go and cgo cause the problem :( Best, changkun -- 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.
