Your description makes no sense. Why are you creating another C thread, you
should just lock the OS thread the Go routine is on. Otherwise if you create
another C thread, in the cgo call you need to block that thread or somehow
communicate back into Go some other way - otherwise what is the point?
> On Sep 29, 2018, at 7:31 AM, changkun <euryugas...@gmail.com> wrote:
>
>
>> On Saturday, September 29, 2018 at 2:08:03 PM UTC+2, Tamás Gulácsi wrote:
>> Yes, but is that a one and only goroutine?
>
> No. The cgo call is opened for every new incoming user request.
>
> Let's summarize:
>
> - Every network request creates a goroutine without response
> processing result to a user of that goroutine.
> - The goroutine instantly proceeds a cgo call and the cgo call
> creates a non-Go thread, then a Pango call pango_font_map_get_default()
> is involved in the non-Go thread.
> - According to pango_font_map_get_default(), it holds a static thread-safe
> variable.
> - The original pure C code is able to proceed execution without involving Go.
> But stuck at the Pango call when involving cgo
> - runtime.LockOSThread doesn't work:
> go func() {
> runtime.LockOSThread()
> handleConnection(timeout)
> runtime.UnlockOSThread()
> }()
>
> --
> 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.
--
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.
