On Sun, Jul 19, 2020 at 11:48 AM Matt Mueller <mattmue...@gmail.com> wrote: > > I'm working on a server-side Javascript rendering package in Go. It uses > https://bellard.org/quickjs/ for it's parser and interpreter. I'm using > https://github.com/lithdew/quickjs to package it with Go. > > Quickjs appears to have some thread-local memory, so I'm use > runtime.LockOSThread() to make sure that the goroutine is always placed on > the same thread. I'm using a worker pattern to distribute load. > > The problem I'm running into is that sometimes worker's goroutines get > scheduled (and then locked) to the same thread, effectively serializing the > computation. This seems random and causes a loss in parallelism since these > goroutines will remain on the same thread through their lifetime. > > Are there any workarounds with this issue?
In this kind of pattern I would expect that the very first thing the new goroutine would do would be to call runtime.LockOSThread, and to only call UnlockOSThread when the goroutine is ready to quit. In that case I don't see how what you describe could happen. Can you describe your calling pattern in more detail? 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/CAOyqgcWd8VquX5zhydwAqXH33S1wbc4NoNuQtu%3DYxc44n0Yijw%40mail.gmail.com.
