Re: "fork" command?

[Richard Gaskin]

Monte Goulding wrote:
>> On 9 Jan 2016, at 6:21 am, Richard Gaskin wrote:
>>
>> If not via forking by what means can we handle concurrency?
>
> For Apache mod_fcgid will start multiple processes for you. As will
> spawn-fcgi if you aren’t running a web server that will do it for you.

Now I'm super-confused: if we already have everything we need for 
FastCGI under Apache, what's all the fuss about?


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://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

Re: "fork" command?

[Monte Goulding]

> On 9 Jan 2016, at 7:33 am, Richard Gaskin  wrote:
> 
> Now I'm super-confused: if we already have everything we need for FastCGI 
> under Apache, what's all the fuss about?

Isn’t it you making the fuss ;-)

We don’t actually have everything. Someone either needs to implement the 
FastCGI protocol in script or create an engine that uses libfcgi to give us a 
fast cgi main loop.

Cheers

Monte
___
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

Re: "fork" command?

[Richard Gaskin]

Monte Goulding wrote:
>> On 9 Jan 2016, at 7:33 am, Richard Gaskin wrote:
>>
>> Now I'm super-confused: if we already have everything we need for
>> FastCGI under Apache, what's all the fuss about?
>
> Isn’t it you making the fuss ;-)

I seem to be in good company, since FastCGI is something you and Todd 
and Andre and many others have expressed an interest in.


I enjoy using LC for workgroup solutions where concurrency needs are 
very modest, but for any potentially-successful public system we need 
scalability beyond what CGI can provide.


If this is too hard to do I suppose we can recommend folks use PHP for 
FastCGI and CPython for socket servers.  I'd just prefer to work in LC 
if possible.



> We don’t actually have everything. Someone either needs to implement
> the FastCGI protocol in script or create an engine that uses libfcgi
> to give us a fast cgi main loop.

Historically, the many discussions about FastCGI support here and 
elsewhere in the LC community over the years have come down to issue 
handling concurrency.  Since so much of LC is made of blocking commands, 
handling of any single connection would in many cases lock up handling 
of all others.


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.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://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

Re: "fork" command?

[Monte Goulding]

> On 9 Jan 2016, at 6:21 am, Richard Gaskin  wrote:
> 
> If not via forking by what means can we handle concurrency?

For Apache mod_fcgid will start multiple processes for you. As will spawn-fcgi 
if you aren’t running a web server that will do it for you.

Cheers

Monte
___
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

Re: "fork" command?

[Monte Goulding]

> 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. 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. I’m sure there’s ways to 
dynamically start up more processes depending on server load too… Mind you it’s 
just as easy to spin up a whole new instance of your VPS these days… maybe in a 
different location closer to your customers.

Cheers

Monte
___
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

Re: "fork" command?

[Richard Gaskin]

Monte Goulding wrote:

>> On 9 Jan 2016, at 9:35 am, Richard Gaskin wrote:
>> ...if one were to make a sort of Node.lc I would imagine they'd
>> need to hand off socket connections to workers, no?
>
> Or you could just act as an intermediary accepting connections from
> whatever is making the request and then routing the incoming data to
> the appropriate child process.

I've used that and it seems to work well enough, but my concern is that 
if scaled large enough it may be even better to not have a single 
instance handling all connections.


Admittedly this is completely theoretical for me at the moment.  I don't 
have any project I'm working on right now that needs to solve the C10k 
problem.  I'm just hoping to ensure that if/when I come up with 
something really successful, I will have built it on a toolkit that can 
scale.  And when we consider Eve Online, we know scripting languages are 
up for the task; I'd just like to have confidence LiveCode is one of them.



> Check the docs for mod_fcgid where there are settings to control the
> number of processes and spawn rate https://httpd.apache.org/mod_fcgid
>/mod/mod_fcgid.html  /mod/mod_fcgid.html>
>
> The nuts of it is that mod_fcgid will start a new process if it has
> permission to and there’s a request but no idle processes.

Good lead to add to my studies.  Thanks.

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://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

Re: "fork" command?

[Monte Goulding]

Isn't that when you deploy your app on EC2 instances with Elasitc Load Balancer 
and all your static content served by CloudFront from S3?

Sent from my iPhone

> On 9 Jan 2016, at 11:45 AM, Richard Gaskin  wrote:
> 
> I've used that and it seems to work well enough, but my concern is that if 
> scaled large enough it may be even better to not have a single instance 
> handling all connections.

___
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

Re: "fork" command?

[Monte Goulding]

It was just an example. There's obviously more than one way to scale.

Sent from my iPhone

> On 9 Jan 2016, at 12:27 PM, Richard Gaskin  wrote:
> 
> If Amazon was the only way to run web sites that assumption would be correct.

___
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

Re: "fork" command?

[Richard Gaskin]

Monte Goulding wrote:
> There's obviously more than one way to scale.

Agreed.  The question I and others may have not far down the road, and 
the question Todd already faced, is whether LiveCode can be a part of it.


If I were to play it safe I could limit LiveCode to the client only, and 
use industry-standard tools for everything on the backend.


But I like LiveCode.  I'd even go so far as to say that I love it.  And 
when I see truly massive systems like Eve Online, and efficient systems 
like Node.js, I see things that are very close to what LiveCode can do 
right now - but is LiveCode close enough to do them?  I don't know. 
That's what I'm hoping to learn.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://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

Re: "fork" command?

[Monte Goulding]

> On 9 Jan 2016, at 9:35 am, Richard Gaskin  wrote:
> 
> 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?

Or you could just act as an intermediary accepting connections from whatever is 
making the request and then routing the incoming data to the appropriate child 
process.
> 
> > 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?

We didn’t get that far
> 
> 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.
> 

We are going around in circles here a bit. Check the docs for mod_fcgid where 
there are settings to control the number of processes and spawn rate 
https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html 


The nuts of it is that mod_fcgid will start a new process if it has permission 
to and there’s a request but no idle processes.

Cheers

Monte

> 
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.comhttp://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

Re: "fork" command?

[Richard Gaskin]

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.



--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://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

Re: "fork" command?

[Richard Gaskin]

Monte Goulding wrote:
> It’s worth noting that FastCGI doesn’t require fork
> http://www.fastcgi.com/drupal/node/6?q=node/22#S3
> so if you are keen to implement FastCGI in script you could
> try doing that now. If fork is implemented then it should be
> easy to add to your implementation.

If not via forking by what means can we handle concurrency?

Multiprocessing through worker apps would be a solution except that we 
have no way to pass the socket connection from the parent app that 
received it to the child app it would launch.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://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

Re: "fork" command?

[Mark Wieder]

On 01/08/2016 05:48 PM, Richard Gaskin wrote:


But I like LiveCode.  I'd even go so far as to say that I love it.  And
when I see truly massive systems like Eve Online, and efficient systems
like Node.js, I see things that are very close to what LiveCode can do
right now - but is LiveCode close enough to do them?  I don't know.
That's what I'm hoping to learn.


It's an interesting philosophy. I usually go the other way around.
I think part of maturing as a developer is being able to pick an 
appropriate tool for a given job. I've had to drop LiveCode as a 
platform for multiple projects when it wasn't up to the job or I hit 
brick walls with it. I'm not much of a php fan, but if it does the job 
on the backend I'm fine with using it. Likewise a Rails frontend when LC 
server isn't up to the task (certificates, totp, etc.).


--
 Mark Wieder
 ahsoftw...@gmail.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

Re: "fork" command?

[Richard Gaskin]

Mark Wieder wrote:

I think part of maturing as a developer is being able to pick an
appropriate tool for a given job.


And as a business owner as well.

I'm willing to explore the question, but I'm not betting my business on 
it; hence the exploration.


It would benefit the community, and by extension the company and even 
myself, if I could help find truly scalable solutions for using LiveCode 
on a server.


But if I can't find 'em I have nothing less than the entire world of 
options all other devs have to choose from. :)


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for Desktop, Mobile, and Web
 
 ambassa...@fourthworld.comhttp://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

Re: "fork" command?

[Mark Waddingham]

On 2016-01-07 20:03, Richard Gaskin 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 you need to read a bit more about fork ;)


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.


The 'fork()' system call is a very low-level primitive which is the 
basis of executing other processes on UNIX based systems. You have to 
use it very carefully - indeed, pretty much any use of fork will almost 
immediately be followed by a call to some variant of 'exec', which 
basically runs a different executable in the current process, replacing 
the original one.



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.


Well 'gives access to' is slightly misleading here as it suggests that 
you can use them all, which isn't really true. When you fork the kernel:


1) clones the task structure (the thing the kernel uses to represent a 
process)


2) marks all memory pages as copy on write

3) increases the reference count on every thing attached to a file 
descriptor


This means that when the child process starts running its memory image 
is identical to the parent, and it has *exactly the same* file 
descriptors as the parent.


Critically, any state which the original process has related to 
connections to things (e.g. databases or display servers) is the same in 
parent and child, which means they have the same 'state' on the other 
end of the connection. This means that any usage of them in either after 
the fork will cause things to break, probably horrendously as the two 
processes run asynchronously.


This means that you need to engineer things so that the child gets 
appropriate fd's and the parent keeps appropriate fd's. The typical 
thing you do here is faff around with pipes. For example, here is the 
critical bit of code from the engine's open process command:


int tochild[2];
int toparent[2];
int4 index = MCnprocesses;
if (pipe(tochild) == 0)
{
if (pipe(toparent) == 0)
{
MCU_realloc((char **), MCnprocesses,
MCnprocesses + 1, sizeof(Streamnode));
MCprocesses[MCnprocesses].name = strclone("shell");
MCprocesses[MCnprocesses].mode = OM_NEITHER;
MCprocesses[MCnprocesses].ohandle = NULL;
MCprocesses[MCnprocesses].ihandle = NULL;
if ((MCprocesses[MCnprocesses++].pid = fork()) == 0)
{
close(tochild[1]);
close(0);
dup(tochild[0]);
close(tochild[0]);
close(toparent[0]);
close(1);
dup(toparent[1]);
close(2);
dup(toparent[1]);
close(toparent[1]);
execl(MCshellcmd, MCshellcmd, "-s", NULL);
_exit(-1);
}
MCS_checkprocesses();
close(tochild[0]);
char *str = path2utf(ep.getsvalue().clone());
write(tochild[1], str, strlen(str));
delete str;
write(tochild[1], "\n", 1);
close(tochild[1]);
close(toparent[1]);
MCS_nodelay(toparent[0]);
if (MCprocesses[index].pid == -1)
{
if (MCprocesses[index].pid > 0)
MCS_kill(MCprocesses[index].pid, SIGKILL);
MCprocesses[index].pid = 0;
MCeerror->add(EE_SHELL_BADCOMMAND, 0, 0, 
ep.getsvalue());

return IO_ERROR;
}
}
else
{
close(tochild[0]);
close(tochild[1]);
MCeerror->add(EE_SHELL_BADCOMMAND, 0, 0, 
ep.getsvalue());

return IO_ERROR;
}
}



But for those of you more familiar with Linux system programming, do I
misunderstand the difficulty involved?


Yes - fork() isn't what you are looking for. It isn't magical - it does 
*precisely* what it says it does which is insufficient for what you are 
proposing (and isn't what it is really used for anywhere).



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.


I'd say forking (except the purpose of implementing the 

Re: "fork" command?

[Richard Gaskin]

Monte Goulding wrote:

>> On 8 Jan 2016, at 6:03 am, Richard Gaskin wrote:
>>
>> 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".
>
>
> 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.

My understanding is that spawn-fcgi uses fork, no?


> 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).

I believe that has more to do with the nature of CGI than with LC per 
se.  That is, as a CGI any engine (Perl, Python, Ruby, LiveCode) will be 
born, live, and die during the request.


But with FastCGI the engine is only loaded once, and instances forked 
with requests as needed, and using fork they get the socket and other 
data needed for the child process to handle the task.


Some engines may use multithreading rather than multiprocessing, but the 
difference is less of a concern on Linux than on Windows since Linux 
spawns processes much more efficiently.


If multithreading were pursued as an alternative to multiprocessing via 
fork, I fear a threading subsystem would be much more work to implement, no?



>  - 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.

How is that handled in the FastCGI version of PHP?  I would imagine it 
would be no more onerous than with threading, arguably simpler since so 
much of the action takes places in a separate process.


I wouldn't expect to be able to use FastCGI without modifying some of my 
scripting habits; as with any new feature, just a few new things to 
learn and keep track of.  Indeed, I would welcome the opportunity for it 
to become possible to learn those things.



> 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   - 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.

In that outline would "acceptRequest" be a request from Apache, or are 
you proposing a system that replaces Apache to accept requests directly 
from the client?


Once we have forking we could completely replace Apache (or NGineX or 
Node.js) with a fully-functioning server for specific applications where 
the efficiencies of a purpose-built system would be helpful.


But even when running under Apache with FastCGI, fork would seem a very 
useful thing.  It's how PHP and other engines are able to scale, and 
indeed not having it prevents LC from being used in traffic-heavy scenarios.



> 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 ;-)

As with other persistent systems like LC on the desktop, we should 
maintain control over which data is purged and which data is shared.  We 
have globals and script-locals, depending on the context we need them, 
and in a multiprocessing environment we should have the same flexibility.


For example, one of the strong advantages of FastCGI or other persistent 
implementation is that we don't have to create and destroy database 
connections with every request.  That sort of information (along with 
config data and other such things) we'd want to remain globally 
available to child processes.  Request-specific data could be handled in 
script-locals, where they can be managed and cleared as needed 

Subject: Re: "fork" command?

[Todd Fabacher]

+1 for Me also

I would for sure would support funding for this. LiveCode in a Node.JS like
solution would be a KILLER!!! Especially if there was a direct connection
to MongoDB which we are HEAVY users of.

--Todd


> Le 7 janv. 2016 ? 20:03, Richard Gaskin  a
?crit :
>
> 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.
>


> 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.
___
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

Re: "fork" command?

[Monte Goulding]

> My understanding is that spawn-fcgi uses fork, no?

Yes. Are you looking to implement your own process manager though?
> 
> 
> > 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).
> 
> I believe that has more to do with the nature of CGI than with LC per se.  
> That is, as a CGI any engine (Perl, Python, Ruby, LiveCode) will be born, 
> live, and die during the request.
> 
> But with FastCGI the engine is only loaded once, and instances forked with 
> requests as needed, and using fork they get the socket and other data needed 
> for the child process to handle the task.

> Some engines may use multithreading rather than multiprocessing, but the 
> difference is less of a concern on Linux than on Windows since Linux spawns 
> processes much more efficiently.
> 
> If multithreading were pursued as an alternative to multiprocessing via fork, 
> I fear a threading subsystem would be much more work to implement, no?

spawn-fcgi and mod_fcgid do essentially what you are proposing. Spawn long 
running processes when told to and manage passing the request to them in a 
balanced way if there’s more than one process.
> 
> 
> >  - 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.
> 
> How is that handled in the FastCGI version of PHP?

PHP tears down everything although you can maintain persistent db connections. 
There’s a few different ways to do FastCGI for PHP as it has it’s own process 
manager.

>  I would imagine it would be no more onerous than with threading, arguably 
> simpler since so much of the action takes places in a separate process.

I actually haven’t mentioned threading at all...
> 
> I wouldn't expect to be able to use FastCGI without modifying some of my 
> scripting habits; as with any new feature, just a few new things to learn and 
> keep track of.  Indeed, I would welcome the opportunity for it to become 
> possible to learn those things.
> 
> In that outline would "acceptRequest" be a request from Apache, or are you 
> proposing a system that replaces Apache to accept requests directly from the 
> client?

acceptRequest would be called in response to the FastCGI main loop which 
processes a requests then waits for the next one to come in. Where it comes 
from is from anything that implements the FastCGI protocol but it is a HTTP 
request if that’s what you are asking.

> 
> Once we have forking we could completely replace Apache (or NGineX or 
> Node.js) with a fully-functioning server for specific applications where the 
> efficiencies of a purpose-built system would be helpful.

Ah, ok so you wan’t MCHTTPd with child processes and maybe FastCGI but maybe 
just some custom protocol between them?
> 
> But even when running under Apache with FastCGI, fork would seem a very 
> useful thing.  It's how PHP and other engines are able to scale, and indeed 
> not having it prevents LC from being used in traffic-heavy scenarios.

I’m not saying it’s not useful, just suggesting letting something else do the 
forking might be a good idea.

> 
> 
> > 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 ;-)
> 
> As with other persistent systems like LC on the desktop, we should maintain 
> control over which data is purged and which data is shared.  We have globals 
> and script-locals, depending on the context we need them, and in a 
> multiprocessing environment we should have the same flexibility.
> 
> For example, one of the strong advantages of FastCGI or other persistent 
> implementation is that we don't have to create and destroy database 
> connections with every request.  That sort of information (along with config 
> data and other such things) we'd want to remain globally available to child 
> processes.  Request-specific data could be handled in script-locals, where 
> they can be managed and cleared as needed within the worker process itself, 
> without affecting truly global data managed by the parent.

I think what I was proposing covers that.

Cheers

Monte


___
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

Re: "fork" command?

[Todd Fabacher]

Yes, Monte is correct, we switch our servers to Node.JS simply because of
the ease of use, speed and productivity gains.

BUT...there is tremendous power is using one language as a solution. The
barrier of entry for most LiveCoders is very high to get a proper cloud
App. If like LC had a solution like Node.JS where you could just drop it on
the server. list your scripts, start up the server and BINGO one cloud
server ready to go - it would be HUGE.  FASTCGI did not offer many
advantages over Node.JS, and we are quite happy with it. but Now I need to
keep a person on staff who specialize it at the cost of over $100K.

The future of LiveCode is the cloud any way you turn, even if you do
traditional desktops. All this talk about HTML5 without a good, simple and
fast web server is just BS because it is the weak link in the chain. Any
productivity gain you might get in HTML5 or LC are going to be killed
trying to create a REST API server for your app.

I would for sure support any web server with this functionality. I also
think this would be a great opportunity to the LC community to step up and
do this on it's own as a independent project and let LC guys stay focused.
What do you think Monti and Richard?

--Todd
___
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

Re: "fork" command?

[Monte Goulding]

> On 8 Jan 2016, at 12:42 pm, Richard Gaskin <ambassa...@fourthworld.com> wrote:
> 
> Monte Goulding wrote:
> 
> >> My understanding is that spawn-fcgi uses fork, no?
> >
> > Yes. Are you looking to implement your own process manager though?
> 
> What constitutes "process manager" in this context?

Something that spawns processes that handle requests.
> 
> 
> >> Once we have forking we could completely replace Apache (or NGineX
> >> or Node.js) with a fully-functioning server for specific
> >> applications where the efficiencies of a purpose-built system would
> >> be helpful.
> >
> > Ah, ok so you wan’t MCHTTPd with child processes and maybe FastCGI
> > but maybe just some custom protocol between them?
> 
> Ideally, both: FastCGI for use under Apache for building Web sites, and a 
> forkable variant of MCHTTPd for building custom application servers.

OK, well these are two quite distinct requests although you could probably 
implement the FastCGI protocol in script and then use your proposed fork 
command if you wanted to load balance over child processes. I was thinking more 
along the lines of using libfcgi directly in the engine. It’s worth noting that 
FastCGI doesn’t require fork (http://www.fastcgi.com/drupal/node/6?q=node/22#S3 
<http://www.fastcgi.com/drupal/node/6?q=node/22#S3>) so if you are keen to 
implement FastCGI in script you could try doing that now. If fork is 
implemented then it should be easy to add to your implementation.
> 
> 
> >> But even when running under Apache with FastCGI, fork would seem
> >> a very useful thing.  It's how PHP and other engines are able to
> >> scale, and indeed not having it prevents LC from being used in
> >> traffic-heavy scenarios.
> >
> > I’m not saying it’s not useful, just suggesting letting something
> > else do the forking might be a good idea.
> 
> I'm not particular how it's done; I'm just looking for options to make 
> scalable services with LC.  What would that "something else" be?

I thought I’d covered that. spawn-fcgi, mod_fcgid or some equivalent.

Cheers

Monte
___
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

Re: "fork" command?

[Pierre Sahores]

> Le 7 janv. 2016 à 20:03, Richard Gaskin  a écrit :
> 
> 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.
> 
<—snip —>

> 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.

+1

Livecode behind NGINX would probably run as fast as OpenResty powered app’s 
servers.

https://www.techempower.com/benchmarks/

Best,

Pierre
--
Pierre Sahores
mobile : 06 03 95 77 70
www.sahores-conseil.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

Re: "fork" command?

[Monte Goulding]

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  On 8 Jan 2016, at 6:03 am, Richard Gaskin  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.comhttp://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

"fork" command?

[Richard Gaskin]

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.comhttp://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

Re: "fork" command?

[Bob Sneidar]

That would be a great addition, although I confess I am highly dependent on the 
"finish what you are doing and move on to the next step" model, or single 
threading as the less tech savy might call it. ;-)

Bob S


> On Jan 7, 2016, at 11:03 , Richard Gaskin  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.comhttp://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