Hi Louis, thanks for the info. However, this FCGI implementation moves the application server one "layer" up, to the realm of .js script. My aim is to create a (cgi) _binary_ which acts as a standard cgi but runs in a loop and executes requested .js scripts.
This implementation differs by the fact that any author of .js script does not need to distinguish between CGI, FastCGI or any other (say apache module) scenario. Exactly as one does with .php scripts... Ondrej Zara 2009/1/5 Louis Santillan <[email protected]>: > > There is already one implementation of FastCGI for v8 in k7 > (http://github.com/sebastien/k7/tree/master & > http://github.com/sebastien/k7/tree/master/lib/net/http/server/fcgi.cpp). > > -Louis > > On Mon, Jan 5, 2009 at 6:07 AM, Ondrej Zara <[email protected]> wrote: >> >>>> 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. >>> >> >> Aha, that sounds reasonable. However, this solution also introduces >> the concept of "forbidden" global object, which previously sounded >> strange to me. Now this makes a lot more sense. On the other hand, one >> cannot effectively load any JS "libraries" which introduce new classes >> (say MySQL, HTTP, ...), because these are created as properties of >> global object, ok? So any javascript code needs to be run inside an >> anonymous function: >> >> (function() { >> [code] >> })(); >> >> because a simple statement "var a = 3;" would pollute the context... >> >>>> 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. >>> >> >> IMHO some form of "save/restore" support would be ideal for this case: >> one would be able to generate a snapshot of created context ready for >> usage... >> >>>> 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. >>> >> >> Okay. However, note that I do not seek a final and polished solution - >> just some ideas and working concepts (with FCGI included, as I was not >> brave enought to dive into it!) :) >> >> >> Sincerely, >> Ondrej Zara >> >> >>> -- >>> Bryan White >>> >>> > >>> >> >> > >> > > > > --~--~---------~--~----~------------~-------~--~----~ v8-users mailing list [email protected] http://groups.google.com/group/v8-users -~----------~----~----~----~------~----~------~--~---
