I would agree with what Mihai is recommending as the way to do this in node.js. You can also get node.js to talk fastcgi in a cluster behind nginx if that's what you want to do.
the issues i think you will still have are: 1) how to prevent, detect and recover from infinite loops in the child processes/contexts 2) how to share data between child processes/contexts in relation to 1) you will probably have to have some kind of heartbeat mechanism between your child processes and the master process so the master can kill off any children that have become unresponsive. this is a tricky problem though as you are essentially setting a maximum time that a loop can run, which may not be what you want to do and will vary depending on the environment. i'm not really sure if a good solution to this problem is possible with node.js/v8, but someone please correct me if i'm wrong. in relation to 2) i think your only real option with node.js/v8 is message passing. this will mean serializing your shared data and sending to the child process which will have to deserialise it, create a context from it and pass this context to a vm.runInContext command to execute it. The object will then have to be serialized again and sent back to the parent process which will have to deserialize it before it can work with it. This is going to mean a lot of cpu overhead and possibly memory usage if your shared objects/messages are large. if you really want to be secure and ensure plugins/scripts don't interfere with each other then you are going to have to spawn lots of separate processes to run scripts in. you can pre-spawn these and just have them waiting for jobs to do, as long as they only do one job at a time. however, each node.js process is going to be pretty large so you will be using up a lot of RAM if you have even hundreds of child processes active (on linux at least 10MB per process on startup and probably of minimum of 20-30MB while working, depending on what you are doing). If most of your plugins/scripts are IO rather than CPU bound then you are losing a lot of the benfits of node.js by doing this and the OS is having to do a lot of extra work to schedule all those processes. no easy answers i am afraid, but am hoping to see node.js/v8 provide better support for this kind of thing in the future... On Monday, March 5, 2012 1:43:15 AM UTC, Luke Scott wrote: > > I'm trying to figure out if Node will work for our platform or not (or > even V8 in general). We're planning a rewrite. We use PHP. We need to allow > users to write server side plugins. For it to be secure in PHP we'd have to > write a "language" using flex/bison to eliminate dynamic function calling > and only allow whitelist functions. I can do this. But users would have to > learn this "new language". Most users, if they have any "web development" > experience, are going to be more familiar with JavaScript. So I'm looking > at V8, and thus I found Node.js. > > Node.js seems very promising. Write the same code on server side and > client side - one language instead of two. JavaScript has an event and > async model built in. Node.js provides a single application instance. > Awesome. > > But what makes Node.js harder to swallow is the single thread. First off - > I get it. No argument from me. You guys won't do a "thread pool"/"fibers", > I understand your reasoning. In most projects this is OK because the > developer has complete control over what code is executed. The code can be > written in an async manner. > > What I'm trying to figure out is what to do when I want users to write > plugins (untrusted code). I only want them to have access to (1) what > V8 vanilla provides and (2) a few classes that provide context sensitive > functions. But with a single thread malicious code goes well beyond what > the user can access - It also includes writing code that blocks. > > As I understand it the only way to ensure a user can't jailbreak or block > the event loop is to run their code in a separate thread, which is > something that won't happen in Node.js. There were some mention of > user-land solutions. But this makes me hesitant because wouldn't a > "user-land" solution be written in JavaScript? > > What I'm looking for would be very much like how Chrome isolates tabs. > Pages from different tabs can't communicate, and if one freezes the whole > browser doesn't lock up. You can either close the frozen tab and/or open > another one. > > I'm not asking you to include this in the core. I'm just trying to figure > out if Node.js works for me in this situation. If there are solutions using > Node.js let me know. If there isn't and Node.js isn't the right fit tell > me. If Node.js doesn't work for me, are there are server V8 projects that > would be more appropriate, like v8cgi, or should I just stick with PHP? > > Also, what kind of applications would you not trust on Node.js? Should > someone like Amazon trust Node to power their shopping cart knowing that > having the one thread fail could prematurely cut off thousands of > in-progress transactions? I'm sure Node.js isn't intended to be the "fit > all" solution for everything. But are there things you would say "you > should never use Node for X, but it would be great for Y"? > > Thank you for your patience :)! > On Monday, March 5, 2012 1:43:15 AM UTC, Luke Scott wrote: > > I'm trying to figure out if Node will work for our platform or not (or > even V8 in general). We're planning a rewrite. We use PHP. We need to allow > users to write server side plugins. For it to be secure in PHP we'd have to > write a "language" using flex/bison to eliminate dynamic function calling > and only allow whitelist functions. I can do this. But users would have to > learn this "new language". Most users, if they have any "web development" > experience, are going to be more familiar with JavaScript. So I'm looking > at V8, and thus I found Node.js. > > Node.js seems very promising. Write the same code on server side and > client side - one language instead of two. JavaScript has an event and > async model built in. Node.js provides a single application instance. > Awesome. > > But what makes Node.js harder to swallow is the single thread. First off - > I get it. No argument from me. You guys won't do a "thread pool"/"fibers", > I understand your reasoning. In most projects this is OK because the > developer has complete control over what code is executed. The code can be > written in an async manner. > > What I'm trying to figure out is what to do when I want users to write > plugins (untrusted code). I only want them to have access to (1) what > V8 vanilla provides and (2) a few classes that provide context sensitive > functions. But with a single thread malicious code goes well beyond what > the user can access - It also includes writing code that blocks. > > As I understand it the only way to ensure a user can't jailbreak or block > the event loop is to run their code in a separate thread, which is > something that won't happen in Node.js. There were some mention of > user-land solutions. But this makes me hesitant because wouldn't a > "user-land" solution be written in JavaScript? > > What I'm looking for would be very much like how Chrome isolates tabs. > Pages from different tabs can't communicate, and if one freezes the whole > browser doesn't lock up. You can either close the frozen tab and/or open > another one. > > I'm not asking you to include this in the core. I'm just trying to figure > out if Node.js works for me in this situation. If there are solutions using > Node.js let me know. If there isn't and Node.js isn't the right fit tell > me. If Node.js doesn't work for me, are there are server V8 projects that > would be more appropriate, like v8cgi, or should I just stick with PHP? > > Also, what kind of applications would you not trust on Node.js? Should > someone like Amazon trust Node to power their shopping cart knowing that > having the one thread fail could prematurely cut off thousands of > in-progress transactions? I'm sure Node.js isn't intended to be the "fit > all" solution for everything. But are there things you would say "you > should never use Node for X, but it would be great for Y"? > > Thank you for your patience :)! > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
