[chrisfarms]

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

[mcuadros]

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]

No 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.