On Tuesday, 4 March 2014 12:12:44 UTC, ajlopez wrote:
>
>
> Thanks!
>
> I mentioned the absent of acronym "translation" not for me, but for the 
> casual reader. It is a bit confused read a post with not defined acronyms.
>
> Ok, child process, but
>
>
>    - Node.js Child Processes handle a single user request at a time
>    - If no Child Process is available, incoming requests are queued
>    - Child Process Pool size is configurable to match demand 
>    - Since a Child Process handles only on request, it can use blocking 
>    I/O and synchronous JavaScript logic
>
> That is not the node.js way/world. You don't need a child process pool in 
> node.js, am I right? Nor in meteor, with fibers.
>

On the face of it, it might not appear to be the conventional Node.js 
approach, but the queue/pre-forked process pool is an architecture used 
frequently in message queue-based systems, and works extremely well and 
very fast in Node.js.  Note that the Child Processes are pre-forked and 
remain running at all times - there's no startup / teardown overhead.


> What is a Node.js Child Process, in your presentation? 
>
> Google gave to me:
> http://nodejs.org/api/child_process.html
> A full OS process?
>
>
See the Node.js documentation on Child 
Processes: http://nodejs.org/api/child_process.html

They're a standard feature of Node.js
 

> In your slide 24, you mention
> "Node.js, but Synchronous Code!"
>
> But what if the code needs to make an http request, using require('http')? 
> The calls are async?
>
> My guess: you wrote sync code to access your mumps data. (like slide 20). 
> But you cannot do anything async in the back end function. Am I right?
>
>
Correct - the side of EWD.js that handles incoming HTTP(s) and WebSocket 
requests and queueing them is fully async, adhering 100% to standard 
Node.js practice.  It's just the logic that requires access to the Mumps 
data within the child processes that you write as synchronous code.  Within 
that same logic you can, of course, make async calls out to other HTTP(s) 
services (or any other async APIs) - it's really not a problem or 
limitation.  Take a look at the Google Drive Synchroniser application that 
I package with the installation - it calls out asynchronously to Google 
Drive's APIs from a Child Process.

I'd recommend running the installer, trying it out and see for yourself how 
it works in practice.

 Rob

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

--- 
You received this message because you are subscribed to the Google Groups 
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to