Question - globals, contexts & threading

I'm trying to understand the capability of ChakraCore in regards to multi-threaded environment with multiple run times and multiple contexts.
We are currently using an older version of Spidermonkey which gives us full control of global objects and can have multiple threads access objects at the same time.

I know this is not possible with ChakraCore. However, I need to understand how & why the global object seems to be tied directly to context. It seems to only way to access the global is to call JsGetGlobalObject(). i.e. There is no JsSetGlobalObject() to allow you to set your own.

One of my use cases is a javascript enabled web server. There is a pool of runtimes and a pool of contexts and a map containing pre-compiled scripts that we use on the contexts for execution speed.

We also need to maintain session state and keep a "Session Global" around between trips to the web server so that all objects and properties exist on the next trip back to the web server.

Assuming i need a context for each session with the web server (since the global is tied to this) how many can I have in my pool at a time? Is a 1000 too many? How lightweight are contexts?

What are the recommendations here regarding context and runtime pools? I was thinking of starting with 5 runtimes.

Where are the standard classes stored? Is this on the global? or someplace else?
We want the standard classes to already exist on the global on the next trip back to the web server to make it as fast as possible.

Is it possible to have a resolver hook so we can lazy load objects into global as needed?

If a session is invalidated we would like to be able to clear the global object while preserving standard classes. Similar to JS_ClearScope() in Spidermonkey.

Lastly, we need need to be able to suspend running a script (similar to JS_SuspendRequest in spidermoney) which we run another backround script on a different context in the same thread and wait for the return before resuming execution of the mainline script.

Spidermonkey has been great, but it has no future for advanced use cases.

Thanks!
Mike