ambassador at fourthworld.com
Fri Jan 8 23:35:49 CET 2016
Monte Goulding wrote:
>> On 9 Jan 2016, at 8:24 am, Richard Gaskin wrote:
>> I'm fine with writing some code so the main process hands off tasks
>> to workers. The issue I've run into is that I've found no way to
>> hand the socket connection to the worker.
> This is unnecessary.
It might seems so because I'm interleaving discussion of two different
desires: FastCGI and scalable socket servers. If this isn't needed for
FastCGI so much the better, but if one were to make a sort of Node.lc I
would imagine they'd need to hand off socket connections to workers, no?
> The basic idea with FastCGI is you have a process sitting there that
> is waiting for a request, handles the request and goes back to
> waiting for the next one. mod_fcgid, spawn_fcgi and I’m sure other
> things take this a step further by farming out the requests over
> multiple processes. Often the processes will have a life of say 500
> requests where they will be killed and replaced to protect against
> memory leaks etc.
Sounds easy. Why didn't Todd just do that back when he was exploring
ways to use FastCGI with LC?
As or my earlier fixation on fork(), it stems from an older discussion
of these issues here with Andre:
As it is, FastCGI is worse than CGI for LC because with CGI we
can answer more than one user at the same time by spawning new
processes. With FastCGI, while the request was being processed,
no other request would be answered. Thats not a FastCGI limitation,
the protocol is way smarter than CGI you receive all requests on
the same port and you're supposed to fork(). Since we have nothing
like forking on LC, we're dead on that front.
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
Ambassador at FourthWorld.com http://www.FourthWorld.com
More information about the use-livecode