Something that kept me busy for a while. An internal (bash) framework sometimes (Isn’t that great! -sigh-) gave unexpected results. Sometimes the timings were too long, and sometimes data was missing. In the end, it was due to a locking issue. A program tried to execute something while forcing an internal lock. Yet the program was waiting until the lock was released. But when in some cases when two programs do this, this causes a deadlock.

The code below is a way to get around this deadlock. It’s an example using “setlock”, yet it shows the concept. Instead of waiting for the program to release the lock (default behaviour with “setlock”), you can script a small loop that comes back after a few seconds. Yet you have to setup the locking mechanism in a manner that it won’t wait for the lock (option -n for “setlock”).

When setting/changing variables within the scope of a subshell. And then attempt to use those variables outside the scope of this subshell won’t give the ‘expected result’.
A subshell has to be seen as a totally seperate process with it’s own environment.
(check a previous entry about processes)

Now the above might seem logical: Subshell, seperate process, … okay. Let’s say you want to pipe the output of a certain command thru a loop. In this loop you can manipulate/filter/… the data. In some cases you might want to set a flag if a certain criteria is met. Here is where it all comes into play. When you pipe an output to any kind of loop, it’ll become a subshell.

So as you might have guessed. The flag you wanted to set won’t cross it’s subshell borders. So you won’t be able to see it outside the loop. And yet again, an output that you might not have expected.

Up in the Clouds

Views are my own

The content of this blog will, at all times, portray my own views. At no time will this reflect the views of the organization I am linked to. Neither can the information provided be used as support statement.