5 ms·
Hi Chris, thanks for your support. Your packages looks like very interesting, I couldn't find it before. About the pool of workers, they share the stack? Or h
by mcuadros 11y ago
Hi Chris, thanks for your support.
Your packages looks like very interesting, I couldn't find it before.
About the pool of workers, they share the stack? Or how you keep the same status on each.
- chrisfarms 11y agoNo the contexts in pools do not share any state. Once you call an Eval from Go-land you'll be tied to context until that Eval returns, but Go-land will yield during that time so other goroutines(/contexts) are free to execute. It's just a convenience for setting up and working with multiple contexts to take advantage of multiple cores. Probably better to think of it like a process-pool. The use case I had was along the lines of: * Bind/Expose a bunch of Go functions to N JS worker contexts. * Execute a large queue of JS-functions using the workers. Spidermonkey did actually have a way to do a kind of shallow copy of a context and save/restore stack, which shared state, however this actually ended up making things much slower for my use as it required locking the threads and constantly copying stacks.