On Mon, Jan 5, 2009 at 7:11 AM, Ondrej Zara <[email protected]> wrote: > > Hi Bryan, > > thanks a lot for your response! Some my comments are included in your code: > >>> 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. >> > > Why do you need to maintain a set of contextes? When the current > "main" script finishes its run phase, I presume that the relevant > context can be thrown away (BTW: how is this done in V8?) because next > Request will have new context... > >> 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. >> > > Understood. So, everything is executed from scratch for each FCGI_Accept(), > ok?
No it is not. The app keeps an unordered_map<string, pagectx> where the key is the full path of the main javascript file that will handle the request. 'pagectx' in this case is a custom object that contains a V8 context, among other things. The pagectx object initializes it self on first reference and when the timestamps of any of its defendant javascript source files change. > >> 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. >> > > This is interesting, but probably not necessary in my scenario: is it > true that each HTTP request receives a "clean" context? > I may or may not have hit the optimal solution. I know it works and is fast. The reason for reusing contexts is to minimize the work done to prepare a context for each request. > Perhaps you would be so kind to share your code with me so I can have > a look at your work? Please? :) It is not really in a sharable form. It evolved from some trial and error and is in dire need of cleanup and reorganization. -- Bryan White --~--~---------~--~----~------------~-------~--~----~ v8-users mailing list [email protected] http://groups.google.com/group/v8-users -~----------~----~----~----~------~----~------~--~---
