6 ms·
I built a package to bridge spidermonkey/Go last year[0]. I ended up doing most of the communication via JSON (after several less stable versions using reflect)
by chrisfarms 11y ago
I built a package to bridge spidermonkey/Go last year[0]. I ended up doing most of the communication via JSON (after several less stable versions using reflect) which was fine for the use-case I had. Unfortunately since it builds spidermonkey and some wrapper code it ruined any chance of "go get" working cleanly which doesn't make it a very attractive package.
CandyJS looks much simpler. Good work.
[0] https://github.com/chrisfarms/jsapi https://github.com/chrisfarms/jsapi
- mcuadros 11y agoHi 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.