Дечји процеси Ноде.јс: Све што треба да знате

Како се користе спавн (), екец (), екецФиле () и форк ()

Ажурирање: Овај чланак је сада део моје књиге „Ноде.јс изван основа“.

Прочитајте ажурирану верзију овог садржаја и више о Нодеу на јсцомплете.цом/ноде-беионд-басицс .

Једнонитне неблокирајуће перформансе у Ноде.јс одлично функционишу за један процес. Али на крају, један процес у једном ЦПУ неће бити довољан да се носи са све већим оптерећењем ваше апликације.

Без обзира колико моћан био ваш сервер, појединачна нит може подржати само ограничено оптерећење.

Чињеница да Ноде.јс ради у једној нити не значи да не можемо искористити више процеса и, наравно, више машина.

Коришћење више процеса је најбољи начин за скалирање апликације Ноде. Ноде.јс је дизајниран за изградњу дистрибуираних апликација са много чворова. Због тога се зове Ноде . Скалабилност се уклапа у платформу и то није нешто о чему почињете да размишљате касније током живота апликације.

Овај чланак је опис дела мог курса Плуралсигхт о Ноде.јс. Тамо покривам сличан садржај у видео формату.

Имајте на уму да ће вам бити потребно добро разумевање догађаја и токова Ноде.јс пре него што прочитате овај чланак. Ако већ нисте, препоручујем вам да прочитате ова два друга чланка пре него што прочитате овај:

Разумевање Ноде.јс архитектуре вођене догађајима

Већина Ноде-ових објеката - попут ХТТП захтева, одговора и токова - имплементирају модул ЕвентЕмиттер како би могли ...

Потоци: Све што треба да знате

Стреамови Ноде.јс имају репутацију тешких за рад и још теже за разумевање. Па, имам добре вести ...

Модул Дечји процеси

Подређени процес можемо лако да вртимо помоћу Ноде-овог child_processмодула и ти подређени процеси могу лако да комуницирају једни с другима помоћу система за размену порука.

child_processМодул нам омогућава да приступите оперативног система функционалности покретањем било команде система унутар, и, дјечије процеса.

Можемо контролирати тај подређени ток улазног тока и слушати његов излазни ток. Такође можемо контролисати аргументе који ће се проследити основној наредби ОС-а и можемо радити све што желимо са излазима те наредбе. Можемо, на пример, извести једну наредбу као улаз у другу (баш као што то радимо у Линук-у), јер нам сви улази и излази ових наредби могу бити представљени помоћу Ноде.јс токова.

Имајте на уму да су примери које ћу користити у овом чланку сви засновани на Линуку. У оперативном систему Виндовс морате да промените команде које користим са њиховим Виндовс алтернативама.

Постоје четири различита начина да се створи процес деце у чвор: spawn(), fork(), exec(), и execFile().

Видећемо разлике између ове четири функције и када користити сваку.

Настали дечји процеси

spawnФункција покреће команду у новом процесу и можемо га користити да прође ову команду никакве аргументе. На пример, ево кода за стварање новог процеса који ће извршити pwdнаредбу.

const { spawn } = require('child_process'); const child = spawn('pwd');

Једноставно деструктурирамо spawnфункцију из child_processмодула и извршавамо је са наредбом ОС као првим аргументом.

Резултат извршавања spawnфункције ( childгорњи објекат) је ChildProcessинстанца која имплементира ЕвентЕмиттер АПИ. То значи да можемо директно регистровати руковаоце догађајима на овом подређеном објекту. На пример, можемо нешто да урадимо када се подређени процес затвори регистрацијом обрађивача за exitдогађај:

child.on('exit', function (code, signal) { console.log('child process exited with ' + `code ${code} and signal ${signal}`); });

Водитељ изнад даје нам излаз codeза подређени процес и signal, ако постоји, који је коришћен за прекид подређеног процеса. Ова signalпроменљива је нула када дете-процес излази нормално.

Остали догађаји који можемо да региструју сировина за са да ChildProcessпримери су disconnect, error, close, и message.

  • disconnectДогађај се емитује када се процес родитељ ручно позива child.disconnectфункцију.
  • errorДогађај се емитује ако се процес не може да се изродио или убијен.
  • closeДогађај се емитује када су stdioтокови процеса детета се затворени.
  • messageДогађај је најважнији. Емитује се када подређени процес користи process.send()функцију за слање порука. Тако родитељи / дете могу комуницирати међусобно. Пример овога видећемо у наставку.

Сваки процес дете такође добија три стандардне stdioтокове, што можемо приступити помоћу child.stdin, child.stdout, и child.stderr.

Када се ти токови затворе, подређени процес који их је користио емитоваће closeдогађај. Овај closeдогађај се разликује од exitдогађаја јер више подређених процеса може делити исте stdioтокове, па излаз једног подређеног процеса не значи да су се токови затворили.

Будући да су сви токови емитери догађаја, можемо слушати различите догађаје на оним stdioтоковима који су прикључени сваком процесу детета. За разлику од уобичајеног процеса, у подређеном процесу, stdout/ stderrтокови су читљиви токови, док је у stdinток могуће писати. Ово је у основи инверзна врста коју налазимо у главном процесу. Догађаји које можемо користити за те токове су стандардни. Што је најважније, на читљивим токовима можемо слушати dataдогађај који ће имати излаз команде или било коју грешку која се наиђе током извршавања команде:

child.stdout.on('data', (data) => { console.log(`child stdout:\n${data}`); }); child.stderr.on('data', (data) => { console.error(`child stderr:\n${data}`); });

Горе наведена два обрађивача оба случаја ће пријавити у главни процес stdoutи stderr. Када извршимо spawnгорњу функцију, излаз pwdнаредбе се исписује и подређени процес излази са кодом 0, што значи да није дошло до грешке.

Аргументе можемо проследити наредби коју spawnфункција извршава помоћу другог аргумента spawnфункције, који је низ свих аргумената који се прослеђују наредби. На пример, да извршимо findкоманду на тренутном директоријуму са -type fаргументом (да наведемо само датотеке), можемо урадити:

const child = spawn('find', ['.', '-type', 'f']);

Ако се током извршења наредбе догоди грешка, на пример, ако дамо горе пронаћи неисправно одредиште, child.stderrdataпокретач догађаја ће се активирати и exitобрађивач догађаја ће пријавити излазни код 1, што значи да је дошло до грешке. Вредности грешака заправо зависе од главног рачунара и врсте грешке.

Дечји процес stdinје ток за писање. Можемо га користити за слање наредбе неком уносу. Као и сваки поток за писање, најлакши начин за његову употребу је употреба pipeфункције. Читљиви ток једноставно преусмјеримо у записљив ток. Будући да је главни процес stdinчитљив ток, можемо га пренети у подређени stdinток процеса . На пример:

const { spawn } = require('child_process'); const child = spawn('wc'); process.stdin.pipe(child.stdin) child.stdout.on('data', (data) => { console.log(`child stdout:\n${data}`); });

In the example above, the child process invokes the wc command, which counts lines, words, and characters in Linux. We then pipe the main process stdin (which is a readable stream) into the child process stdin (which is a writable stream). The result of this combination is that we get a standard input mode where we can type something and when we hit Ctrl+D, what we typed will be used as the input of the wc command.

We can also pipe the standard input/output of multiple processes on each other, just like we can do with Linux commands. For example, we can pipe the stdout of the find command to the stdin of the wc command to count all the files in the current directory:

const { spawn } = require('child_process'); const find = spawn('find', ['.', '-type', 'f']); const wc = spawn('wc', ['-l']); find.stdout.pipe(wc.stdin); wc.stdout.on('data', (data) => { console.log(`Number of files ${data}`); });

I added the -l argument to the wc command to make it count only the lines. When executed, the code above will output a count of all files in all directories under the current one.

Shell Syntax and the exec function

By default, the spawn function does not create a shell to execute the command we pass into it. This makes it slightly more efficient than the exec function, which does create a shell. The exec function has one other major difference. It buffers the command’s generated output and passes the whole output value to a callback function (instead of using streams, which is what spawn does).

Here’s the previous find | wc example implemented with an exec function.

const { exec } = require('child_process'); exec('find . -type f | wc -l', (err, stdout, stderr) => { if (err) { console.error(`exec error: ${err}`); return; } console.log(`Number of files ${stdout}`); });

Since the exec function uses a shell to execute the command, we can use the shell syntax directly here making use of the shell pipe feature.

Note that using the shell syntax comes at a security risk if you’re executing any kind of dynamic input provided externally. A user can simply do a command injection attack using shell syntax characters like ; and $ (for example, command + ’; rm -rf ~’ )

The exec function buffers the output and passes it to the callback function (the second argument to exec) as the stdout argument there. This stdout argument is the command’s output that we want to print out.

The exec function is a good choice if you need to use the shell syntax and if the size of the data expected from the command is small. (Remember, exec will buffer the whole data in memory before returning it.)

The spawn function is a much better choice when the size of the data expected from the command is large, because that data will be streamed with the standard IO objects.

We can make the spawned child process inherit the standard IO objects of its parents if we want to, but also, more importantly, we can make the spawn function use the shell syntax as well. Here’s the same find | wc command implemented with the spawn function:

const child = spawn('find . -type f | wc -l', { stdio: 'inherit', shell: true });

Because of the stdio: 'inherit' option above, when we execute the code, the child process inherits the main process stdin, stdout, and stderr. This causes the child process data events handlers to be triggered on the main process.stdout stream, making the script output the result right away.

Because of the shell: true option above, we were able to use the shell syntax in the passed command, just like we did with exec. But with this code, we still get the advantage of the streaming of data that the spawn function gives us. This is really the best of both worlds.

There are a few other good options we can use in the last argument to the child_process functions besides shell and stdio. We can, for example, use the cwd option to change the working directory of the script. For example, here’s the same count-all-files example done with a spawn function using a shell and with a working directory set to my Downloads folder. The cwd option here will make the script count all files I have in ~/Downloads:

const child = spawn('find . -type f | wc -l', { stdio: 'inherit', shell: true, cwd: '/Users/samer/Downloads' });

Another option we can use is the env option to specify the environment variables that will be visible to the new child process. The default for this option is process.env which gives any command access to the current process environment. If we want to override that behavior, we can simply pass an empty object as the env option or new values there to be considered as the only environment variables:

const child = spawn('echo $ANSWER', { stdio: 'inherit', shell: true, env: { ANSWER: 42 }, });

The echo command above does not have access to the parent process’s environment variables. It can’t, for example, access $HOME, but it can access $ANSWER because it was passed as a custom environment variable through the env option.

One last important child process option to explain here is the detached option, which makes the child process run independently of its parent process.

Assuming we have a file timer.js that keeps the event loop busy:

setTimeout(() => { // keep the event loop busy }, 20000);

We can execute it in the background using the detached option:

const { spawn } = require('child_process'); const child = spawn('node', ['timer.js'], { detached: true, stdio: 'ignore' }); child.unref();

The exact behavior of detached child processes depends on the OS. On Windows, the detached child process will have its own console window while on Linux the detached child process will be made the leader of a new process group and session.

If the unref function is called on the detached process, the parent process can exit independently of the child. This can be useful if the child is executing a long-running process, but to keep it running in the background the child’s stdio configurations also have to be independent of the parent.

The example above will run a node script (timer.js) in the background by detaching and also ignoring its parent stdio file descriptors so that the parent can terminate while the child keeps running in the background.

The execFile function

If you need to execute a file without using a shell, the execFile function is what you need. It behaves exactly like the exec function, but does not use a shell, which makes it a bit more efficient. On Windows, some files cannot be executed on their own, like .bat or .cmd files. Those files cannot be executed with execFile and either exec or spawn with shell set to true is required to execute them.

The *Sync function

The functions spawn, exec, and execFile from the child_process module also have synchronous blocking versions that will wait until the child process exits.

const { spawnSync, execSync, execFileSync, } = require('child_process');

Those synchronous versions are potentially useful when trying to simplify scripting tasks or any startup processing tasks, but they should be avoided otherwise.

The fork() function

The fork function is a variation of the spawn function for spawning node processes. The biggest difference between spawn and fork is that a communication channel is established to the child process when using fork, so we can use the send function on the forked process along with the global process object itself to exchange messages between the parent and forked processes. We do this through the EventEmitter module interface. Here’s an example:

The parent file, parent.js:

const { fork } = require('child_process'); const forked = fork('child.js'); forked.on('message', (msg) => { console.log('Message from child', msg); }); forked.send({ hello: 'world' });

The child file, child.js:

process.on('message', (msg) => { console.log('Message from parent:', msg); }); let counter = 0; setInterval(() => { process.send({ counter: counter++ }); }, 1000);

In the parent file above, we fork child.js (which will execute the file with the node command) and then we listen for the message event. The message event will be emitted whenever the child uses process.send, which we’re doing every second.

To pass down messages from the parent to the child, we can execute the send function on the forked object itself, and then, in the child script, we can listen to the message event on the global process object.

When executing the parent.js file above, it’ll first send down the { hello: 'world' } object to be printed by the forked child process and then the forked child process will send an incremented counter value every second to be printed by the parent process.

Let’s do a more practical example about the fork function.

Let’s say we have an http server that handles two endpoints. One of these endpoints (/compute below) is computationally expensive and will take a few seconds to complete. We can use a long for loop to simulate that:

const http = require('http'); const longComputation = () => { let sum = 0; for (let i = 0; i  { if (req.url === '/compute') { const sum = longComputation(); return res.end(`Sum is ${sum}`); } else { res.end('Ok') } }); server.listen(3000);

This program has a big problem; when the the /compute endpoint is requested, the server will not be able to handle any other requests because the event loop is busy with the long for loop operation.

There are a few ways with which we can solve this problem depending on the nature of the long operation but one solution that works for all operations is to just move the computational operation into another process using fork.

We first move the whole longComputation function into its own file and make it invoke that function when instructed via a message from the main process:

In a new compute.js file:

const longComputation = () => { let sum = 0; for (let i = 0; i  { const sum = longComputation(); process.send(sum); });

Now, instead of doing the long operation in the main process event loop, we can fork the compute.js file and use the messages interface to communicate messages between the server and the forked process.

const http = require('http'); const { fork } = require('child_process'); const server = http.createServer(); server.on('request', (req, res) => { if (req.url === '/compute') { const compute = fork('compute.js'); compute.send('start'); compute.on('message', sum => { res.end(`Sum is ${sum}`); }); } else { res.end('Ok') } }); server.listen(3000);

When a request to /compute happens now with the above code, we simply send a message to the forked process to start executing the long operation. The main process’s event loop will not be blocked.

Once the forked process is done with that long operation, it can send its result back to the parent process using process.send.

У родитељском процесу слушамо messageдогађај на самом рачвастом детету. Када добијемо тај догађај, имаћемо sumспремну вредност коју ћемо послати кориснику који захтева преко хттп.

Горњи код је, наравно, ограничен бројем процеса које можемо форкирати, али када га извршимо и захтевамо дугачку крајњу тачку израчунавања преко хттп, главни сервер уопште није блокиран и може да прима даље захтеве.

clusterМодул Ноде-а , који је тема мог следећег чланка, заснован је на овој идеји подређивања виљушка процеса и балансирања оптерећења између многих вилица које можемо створити на било ком систему.

То је све што имам за ову тему. Хвала за читање! До следећег пута!

Реагујући или чвор учења? Проверите моје књиге:

  • Научите Реацт.јс градећи игре
  • Ноде.јс изван основа