|
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
|
|
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
|
|
<channel>
|
|
<title>Posts on Fr1nge's Personal Blog</title>
|
|
<link>http://fr1nge.xyz/posts/</link>
|
|
<description>Recent content in Posts on Fr1nge's Personal Blog</description>
|
|
<generator>Hugo -- gohugo.io</generator>
|
|
<language>en-us</language>
|
|
<copyright>Yigit Colakoglu</copyright>
|
|
<lastBuildDate>Wed, 05 May 2021 17:08:12 +0300</lastBuildDate><atom:link href="http://fr1nge.xyz/posts/index.xml" rel="self" type="application/rss+xml" />
|
|
<item>
|
|
<title>Supercharge Your Bash Scripts with Multiprocessing</title>
|
|
<link>http://fr1nge.xyz/posts/supercharge-your-bash-scripts-with-multiprocessing/</link>
|
|
<pubDate>Wed, 05 May 2021 17:08:12 +0300</pubDate>
|
|
|
|
<guid>http://fr1nge.xyz/posts/supercharge-your-bash-scripts-with-multiprocessing/</guid>
|
|
<description>Bash is a great tool for automating tasks and improving you work flow. However, it is SLOW. Adding multiprocessing to the scripts you write can improve the performance greatly.
|
|
What is multiprocessing? In the simplest terms, multiprocessing is the principle of splitting the computations or jobs that a script has to do and running them on different processes. In even simpler terms however, multiprocessing is the computer science equivalent of hiring more than one worker when you are constructing a building.</description>
|
|
<content><p>Bash is a great tool for automating tasks and improving you work flow. However,
|
|
it is <em><strong>SLOW</strong></em>. Adding multiprocessing to the scripts you write can improve
|
|
the performance greatly.</p>
|
|
<h2 id="what-is-multiprocessing">What is multiprocessing?</h2>
|
|
<p>In the simplest terms, multiprocessing is the principle of splitting the
|
|
computations or jobs that a script has to do and running them on different
|
|
processes. In even simpler terms however, multiprocessing is the computer
|
|
science equivalent of hiring more than one
|
|
worker when you are constructing a building.</p>
|
|
<h3 id="introducing-">Introducing &ldquo;&amp;&rdquo;</h3>
|
|
<p>While implementing multiprocessing the sign <code>&amp;</code> is going to be our greatest
|
|
friend. It is an essential sign if you are writing bash scripts and a very
|
|
useful tool in general when you are in the terminal. What <code>&amp;</code> does is that it
|
|
makes the command you added it to the end of run in the background and allows
|
|
the rest of the script to continue running as the command runs in the
|
|
background. One thing to keep in mind is that since it creates a fork of the
|
|
process you ran the command on, if you change a variable that the command in the
|
|
background uses while it runs, it will not be affected. Here is a simple
|
|
example:</p>
|
|
|
|
|
|
|
|
<div class="collapsable-code">
|
|
<input id="1" type="checkbox" />
|
|
<label for="1">
|
|
<span class="collapsable-code__language">bash</span>
|
|
|
|
<span class="collapsable-code__toggle" data-label-expand="Show" data-label-collapse="Hide"></span>
|
|
</label>
|
|
<pre class="language-bash" ><code>
|
|
foo=&#34;yeet&#34;
|
|
|
|
function run_in_background(){
|
|
sleep 0.5
|
|
echo &#34;The value of foo in the function run_in_background is $foo&#34;
|
|
}
|
|
|
|
run_in_background &amp; # Spawn the function run_in_background in the background
|
|
foo=&#34;YEET&#34;
|
|
echo &#34;The value of foo changed to $foo.&#34;
|
|
wait # wait for the background process to finish
|
|
</code></pre>
|
|
</div>
|
|
|
|
|
|
<p>This should output:</p>
|
|
<pre><code>The value of foo changed to YEET.
|
|
The value of foo in here is yeet
|
|
</code></pre><p>As you can see, the value of <code>foo</code> did not change in the background process even though
|
|
we changed it in the main function.</p>
|
|
<h2 id="baby-steps">Baby steps&hellip;</h2>
|
|
<p>Just like anything related to computer science, there is more than one way of
|
|
achieving our goal. We are going to take the easier, less intimidating but less
|
|
efficient route first before moving on to the big boy implementation. Let&rsquo;s open up vim and get to scripting!
|
|
First of all, let&rsquo;s write a very simple function that allows us to easily test
|
|
our implementation:</p>
|
|
|
|
|
|
|
|
<div class="collapsable-code">
|
|
<input id="1" type="checkbox" />
|
|
<label for="1">
|
|
<span class="collapsable-code__language">bash</span>
|
|
|
|
<span class="collapsable-code__toggle" data-label-expand="Show" data-label-collapse="Hide"></span>
|
|
</label>
|
|
<pre class="language-bash" ><code>
|
|
function tester(){
|
|
# A function that takes an int as a parameter and sleeps
|
|
echo &#34;$1&#34;
|
|
sleep &#34;$1&#34;
|
|
echo &#34;ENDED $1&#34;
|
|
}
|
|
</code></pre>
|
|
</div>
|
|
|
|
|
|
<p>Now that we have something to run in our processes, we now need to spawn several
|
|
of them in controlled manner. Controlled being the keyword here. That&rsquo;s because
|
|
each system has a maximum number of processes that can be spawned (You can find
|
|
that out with the command <code>ulimit -u</code>). In our case, we want to limit the
|
|
processes being ran to the variable <code>num_processes</code>. Here is the implementation:</p>
|
|
|
|
|
|
|
|
<div class="collapsable-code">
|
|
<input id="1" type="checkbox" />
|
|
<label for="1">
|
|
<span class="collapsable-code__language">bash</span>
|
|
|
|
<span class="collapsable-code__toggle" data-label-expand="Show" data-label-collapse="Hide"></span>
|
|
</label>
|
|
<pre class="language-bash" ><code>
|
|
num_processes=$1
|
|
pcount=0
|
|
for i in {1..10}; do
|
|
((pcount=pcount%num_processes));
|
|
((pcount&#43;&#43;==0)) &amp;&amp; wait
|
|
tester $i &amp;
|
|
done
|
|
</code></pre>
|
|
</div>
|
|
|
|
|
|
<p>What this loop does is that it takes the number of processes you would like to
|
|
spawn as an argument and runs <code>tester</code> in that many processes. Go ahead and test it out!
|
|
You might notice however that the processes are run int batches. And the size of
|
|
batches is the <code>num_processes</code> variable. The reason this happens is because
|
|
every time we spawn <code>num_processes</code> processes, we <code>wait</code> for all the processes
|
|
to end. This implementation is not a problem in itself, there are many cases
|
|
where you can use this implementation and it works perfectly fine. However, if
|
|
you don&rsquo;t want this to happen, we have to dump this naive approach all together
|
|
and improve our tool belt.</p>
|
|
<h2 id="real-chads-use-job-pools">Real Chads use Job Pools</h2>
|
|
<p>The solution to the bottleneck that was introduced in our previous approach lies
|
|
in using job pools. Job pools are where jobs created by a main process get sent
|
|
and wait to get executed. This approach solves our problems because instead of
|
|
spawning a new process for every copy and waiting for all the processes to
|
|
finish we instead only create a set number of processes(workers) which
|
|
continuously pick up jobs from the job pool not waiting for any other process to finish.
|
|
Here is the implementation that uses job pools. Brace yourselves, because it is
|
|
kind of complicated.</p>
|
|
|
|
|
|
|
|
<div class="collapsable-code">
|
|
<input id="1" type="checkbox" />
|
|
<label for="1">
|
|
<span class="collapsable-code__language">bash</span>
|
|
|
|
<span class="collapsable-code__toggle" data-label-expand="Show" data-label-collapse="Hide"></span>
|
|
</label>
|
|
<pre class="language-bash" ><code>
|
|
job_pool_end_of_jobs=&#34;NO_JOB_LEFT&#34;
|
|
job_pool_job_queue=/tmp/job_pool_job_queue_$$
|
|
job_pool_progress=/tmp/job_pool_progress_$$
|
|
job_pool_pool_size=-1
|
|
job_pool_nerrors=0
|
|
|
|
function job_pool_cleanup()
|
|
{
|
|
rm -f ${job_pool_job_queue}
|
|
rm -f ${job_pool_progress}
|
|
}
|
|
|
|
function job_pool_exit_handler()
|
|
{
|
|
job_pool_stop_workers
|
|
job_pool_cleanup
|
|
}
|
|
|
|
function job_pool_worker()
|
|
{
|
|
local id=$1
|
|
local job_queue=$2
|
|
local cmd=
|
|
local args=
|
|
|
|
exec 7&lt;&gt; ${job_queue}
|
|
while [[ &#34;${cmd}&#34; != &#34;${job_pool_end_of_jobs}&#34; &amp;&amp; -e &#34;${job_queue}&#34; ]]; do
|
|
flock --exclusive 7
|
|
IFS=$&#39;\v&#39;
|
|
read cmd args &lt;${job_queue}
|
|
set -- ${args}
|
|
unset IFS
|
|
flock --unlock 7
|
|
if [[ &#34;${cmd}&#34; == &#34;${job_pool_end_of_jobs}&#34; ]]; then
|
|
echo &#34;${cmd}&#34; &gt;&amp;7
|
|
else
|
|
{ ${cmd} &#34;$@&#34; ; }
|
|
fi
|
|
|
|
done
|
|
exec 7&gt;&amp;-
|
|
}
|
|
|
|
function job_pool_stop_workers()
|
|
{
|
|
echo ${job_pool_end_of_jobs} &gt;&gt; ${job_pool_job_queue}
|
|
wait
|
|
}
|
|
|
|
function job_pool_start_workers()
|
|
{
|
|
local job_queue=$1
|
|
for ((i=0; i&lt;${job_pool_pool_size}; i&#43;&#43;)); do
|
|
job_pool_worker ${i} ${job_queue} &amp;
|
|
done
|
|
}
|
|
|
|
function job_pool_init()
|
|
{
|
|
local pool_size=$1
|
|
job_pool_pool_size=${pool_size:=1}
|
|
rm -rf ${job_pool_job_queue}
|
|
rm -rf ${job_pool_progress}
|
|
touch ${job_pool_progress}
|
|
mkfifo ${job_pool_job_queue}
|
|
echo 0 &gt;${job_pool_progress} &amp;
|
|
job_pool_start_workers ${job_pool_job_queue}
|
|
}
|
|
|
|
function job_pool_shutdown()
|
|
{
|
|
job_pool_stop_workers
|
|
job_pool_cleanup
|
|
}
|
|
|
|
function job_pool_run()
|
|
{
|
|
if [[ &#34;${job_pool_pool_size}&#34; == &#34;-1&#34; ]]; then
|
|
job_pool_init
|
|
fi
|
|
printf &#34;%s\v&#34; &#34;$@&#34; &gt;&gt; ${job_pool_job_queue}
|
|
echo &gt;&gt; ${job_pool_job_queue}
|
|
}
|
|
|
|
function job_pool_wait()
|
|
{
|
|
job_pool_stop_workers
|
|
job_pool_start_workers ${job_pool_job_queue}
|
|
}
|
|
</code></pre>
|
|
</div>
|
|
|
|
|
|
<p>Ok&hellip; But that the actual fuck is going in here???</p>
|
|
<h3 id="fifo-and-flock">fifo and flock</h3>
|
|
<p>In order to understand what this code is doing, you first need to understand two
|
|
key commands that we are using, <code>fifo</code> and <code>flock</code>. Despite their complicated
|
|
names, they are actually quite simple. Let&rsquo;s check their man pages to figure out
|
|
their purposes, shall we?</p>
|
|
<h4 id="man-fifo">man fifo</h4>
|
|
<p>fifo&rsquo;s man page tells us that:</p>
|
|
<pre><code>NAME
|
|
fifo - first-in first-out special file, named pipe
|
|
|
|
DESCRIPTION
|
|
A FIFO special file (a named pipe) is similar to a pipe, except that
|
|
it is accessed as part of the filesystem. It can be opened by multiple
|
|
processes for reading or writing. When processes are exchanging data
|
|
via the FIFO, the kernel passes all data internally without writing it
|
|
to the filesystem. Thus, the FIFO special file has no contents on the
|
|
filesystem; the filesystem entry merely serves as a reference point so
|
|
that processes can access the pipe using a name in the filesystem.
|
|
</code></pre><p>So put in <strong>very</strong> simple terms, a fifo is a named pipe that can allows
|
|
communication between processes. Using a fifo allows us to loop through the jobs
|
|
in the pool without having to delete them manually, because once we read them
|
|
with <code>read cmd args &lt; ${job_queue}</code>, the job is out of the pipe and the next
|
|
read outputs the next job in the pool. However the fact that we have multiple
|
|
processes introduces one caveat, what if two processes access the pipe at the
|
|
same time? They would run the same command and we don&rsquo;t want that. So we resort
|
|
to using <code>flock</code>.</p>
|
|
<h4 id="man-flock">man flock</h4>
|
|
<p>flock&rsquo;s man page defines it as:</p>
|
|
<pre><code> SYNOPSIS
|
|
flock [options] file|directory command [arguments]
|
|
flock [options] file|directory -c command
|
|
flock [options] number
|
|
|
|
DESCRIPTION
|
|
This utility manages flock(2) locks from within shell scripts or from
|
|
the command line.
|
|
|
|
The first and second of the above forms wrap the lock around the
|
|
execution of a command, in a manner similar to su(1) or newgrp(1).
|
|
They lock a specified file or directory, which is created (assuming
|
|
appropriate permissions) if it does not already exist. By default, if
|
|
the lock cannot be immediately acquired, flock waits until the lock is
|
|
available.
|
|
|
|
The third form uses an open file by its file descriptor number. See
|
|
the examples below for how that can be used.
|
|
</code></pre><p>Cool, translated to modern English that us regular folks use, <code>flock</code> is a thin
|
|
wrapper around the C standard function <code>flock</code> (see <code>man 2 flock</code> if you are
|
|
interested). It is used to manage locks and has several forms. The one we are
|
|
interested in is the third one. According to the man page, it uses and open file
|
|
by its <strong>file descriptor number</strong>. Aha! so that was the purpose of the <code>exec 7&lt;&gt; ${job_queue}</code> calls in the <code>job_pool_worker</code> function. It would essentially
|
|
assign the file descriptor 7 to the fifo <code>job_queue</code> and afterwards lock it with
|
|
<code>flock --exclusive 7</code>. Cool. This way only one process at a time can read from
|
|
the fifo <code>job_queue</code></p>
|
|
<h2 id="great-but-how-do-i-use-this">Great! But how do I use this?</h2>
|
|
<p>It depends on your preference, you can either save this in a file(e.g.
|
|
job_pool.sh) and source it in your bash script. Or you can simply paste it
|
|
inside an existing bash script. Whatever tickles your fancy. I have also
|
|
provided an example that replicates our first implementation. Just paste the
|
|
below code under our &ldquo;chad&rdquo; job pool script.</p>
|
|
|
|
|
|
|
|
<div class="collapsable-code">
|
|
<input id="1" type="checkbox" />
|
|
<label for="1">
|
|
<span class="collapsable-code__language">bash</span>
|
|
|
|
<span class="collapsable-code__toggle" data-label-expand="Show" data-label-collapse="Hide"></span>
|
|
</label>
|
|
<pre class="language-bash" ><code>
|
|
function tester(){
|
|
# A function that takes an int as a parameter and sleeps
|
|
echo &#34;$1&#34;
|
|
sleep &#34;$1&#34;
|
|
echo &#34;ENDED $1&#34;
|
|
}
|
|
|
|
num_workers=$1
|
|
job_pool_init $num_workers
|
|
pcount=0
|
|
for i in {1..10}; do
|
|
job_pool_run tester &#34;$i&#34;
|
|
done
|
|
|
|
job_pool_wait
|
|
job_pool_shutdown
|
|
</code></pre>
|
|
</div>
|
|
|
|
|
|
<p>Hopefully this article was(or will be) helpful to you. From now on, you don&rsquo;t
|
|
ever have to write single threaded bash scripts like normies :)</p>
|
|
</content>
|
|
</item>
|
|
|
|
</channel>
|
|
</rss>
|