Hmm… I’m not convinced we need this for FastCGI. Apache mod_fcgid will start up processes for you and for Nginx and other servers that don’t do that you could use spawn-fcgi. I have done some thinking on FastCGI after Todd asked me to look into the feasibility of it and was considering funding or part funding it. He ended up going with another platform for server side stuff so its been put on the back burner.
We mainly need two things for FastCGI: - an engine with the FastCGI accept loop as the main loop (LC Server just starts up and quits at the end of the code and standalones just keep looping until you quit). - to decide on how to handle things like global variable scope etc because you’re going to end up with multiple requests to the same environment. After some thought and considering the new script only stack format I came to the conclusion that it would be better not to do the php style <?lc tags and just use a script only stack with messages: - startup - the process is started do anything you can do once for all requests - acceptRequest - a new request needs to be handled and the global environment variables $_SERVER etc have been updated where necessary (or these could be parameters I guess) - shutdown - something is killing the process so do anything you need to do to cleanup The basic idea is you can do something like this: local sCounter = 0 local sProcessStarted on startup put the seconds into sProcessStarted end startup on acceptRequest add 1 to sCounter put “Started:” && sProcessStarted & return & “Counter:” && sCounter end acceptRequest If you only spawn one process then each time you hit the server the counter would increment. Of course you could have a FastCGI engine that cleared all the globals and stacks from memory between requests and loaded any script only stack file but it’s not quite as much fun, you lose the advantage of keeping resources in memory and as far as I can tell it’s a bit more work to do that ;-) Cheers Monte > On 8 Jan 2016, at 6:03 am, Richard Gaskin <ambassa...@fourthworld.com> wrote: > > I'm just far enough into Robert Love's "Linux System Programming" that I > think the solution to FastCGI may be much simpler than I'd previously thought. > > I think we need a new command that launches a specified process but in a way > that uses a call to "fork" to pass file descriptors (which include sockets > and other I/O info) to the child process. > > In many ways it would work very similarly to the existing "open process", but > allow params to give the child process access to things like socket > connections, pipes, files, etc. the parent process has access to at the time > the child process is launched. > > It would seem least intrusive on the code base to implement it as a new > command, perhaps called "fork". > > That said, I have to admit the risk of Dunning-Kruger effect here: I'm not > that far into the book, and my knowledge in this area is far below my > aspirations. > > But for those of you more familiar with Linux system programming, do I > misunderstand the difficulty involved? > > Forking seems so common in other tools, and not having it appears to be the > one detail standing between where we are now and having not just FastCGI, but > also being able to build truly excellent application servers on par with > Node.js and other similar systems. > > LiveCode is a great language, and if we had the ability to fork we should be > able to build a wide range of powerful, scalable, efficient systems, breaking > far beyond the limitations of CGI we're limited to now. > > If all we need is a new command to wrap the Linux "fork" call, after I finish > Love's book I may brush up on my C skills and give it a go. > > But who wants to wait for that. Is there anyone in our community who could > do this now? > > Do I misunderstand what's needed here? > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for the Desktop, Mobile, and the Web > ____________________________________________________________________ > ambassa...@fourthworld.com http://www.FourthWorld.com > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
