On Mon, Jan 5, 2009 at 5:22 AM, ondras <[email protected]> wrote: > > I am thinking about the possibility of a FastCGI application around > V8. However, I am not sure whether this is reasonably realizable:
I have done this (v8 + FastCGI) and it works well. This is how I did it: The app does nothing until it accepts a request. It then looks at the request and determines what javascript file will handle it. It maintains a set of contexts, demand created, one for each request handler program. On creation, the context's global template is populated with a bunch of functions for C++ provided services. Then the javascript file is compiled and run. Note, 'run' here does not mean handle the request. It in effect just fills out the context global object with functions and constant data. During the phase, the javascript may call a provided function for loading other javascript modules. This can happen recursively and the loader function ensures that a module is only loaded once. Once the app has a new or reused context to handle the request, it creates a global Request object with request specific data and calls a HandleRequest function to process the request. Also I wanted to prevent web developers from polluting the context global object. This was to keep the object clean for reuse. V8 snap shots may have been an option here but I never did really understand how they worked. My solution was to install a global 'set' interceptor that threw exceptions if invoked during the HandleRequest phase. If the web developers need global data they can store it in the Request object as that is precreated and recreated before each request. Persistent application session data is accessed via C++ call back. -- Bryan White --~--~---------~--~----~------------~-------~--~----~ v8-users mailing list [email protected] http://groups.google.com/group/v8-users -~----------~----~----~----~------~----~------~--~---
