PHP shutdown handlers and exit codes

I was in bed trying to get to sleep but my brain wanted to know the answer to this question. So I was forced out of bed to write this experiment:

function main( $argv ) {

  register_shutdown_function( 'shutdown_1' );
  register_shutdown_function( 'shutdown_2' );

  exit( 0 );

}

function shutdown_1() {

  exit( 1 );

}

function shutdown_2() {

  exit( 2 );

}

main( $argv );

With this PHP code, what do you expect is the resultant error level?

The answer is ‘1’. After main() calls exit( 0 ) the shutdown function shutdown_1() is invoked. When shutdown_1() calls exit( 1 ) the process exists and shutdown_2() is never called.

I’m glad we cleared that up. Back to bed.

New website: Take Two

Hey Craig. I’ve made some changes (hopefully improvements!) to the website:

Only the home page is working at the moment. I will get the other pages working soon, hopefully today.

Please do let me know (in no uncertain terms!) what you think of the new design. I’ve gone “mobile first”, so it should look respectable on your smart phone.

Context object versus global variables

I’m reading A Philosophy of Software Design by John Ousterhout and he says:

The context object unifies the handling of all system-global information and eliminates the need for pass-through variables. If a new variable needs to be added, it can be added to the context object; no existing code is affected except for the constructor and destructor for the context. The context makes it easy to identify and manage the global state of the system, since it is all stored in one place. The context is also convenient for testing: test code can change the global configuration of the application by modifying fields in the context. It would be much more difficult to implement such changes if the system used pass-through variables.

Contexts are far from an ideal solution. The variables stored in a context have most of the disadvantages of global variables; for example, it may not be obvious why a particular variable is present, or where it is used. Without discipline, a context can turn into a huge grab-bag of data that creates nonobvious dependencies throughout the system. Contexts may also create thread-safety issues; the best way to avoid problems is for variables in a context to be immutable. Unfortunately, I haven’t found a better solution than contexts.

Okay, so I’m just gonna step way out of line over here and suggest something heretical… but shouldn’t you just use global variables? You only introduced the context object so you could tweak it in unit tests, and you could just change your tests so that each one ran in a new process. Just sayin’.

…I suppose for the sake of completeness I should add a little more from Ousterhout which he said prior to the above:

Another approach is to store the information in a global variable, as in Figure 7.2(c). This avoids the need to pass the information from method to method, but global variables almost always create other problems. For example, global variables make it impossible to create two independent instances of the same system in the same process, since accesses to the global variables will conflict. It may seem unlikely that you would need multiple instances in production, but they are often useful in testing.

…so he is bending over backward to support multiple tests in one process, but he could just run each test in its own process and his problem evaporates.

Transferring large files with Salt file.managed

Well, this took me a few hours to figure out.

If you’re going to be transferring large files using file.managed in your salt state, make sure you specify show_changes: False, otherwise salt will start trying to boil the ocean and calculate the unified diff of your enormous files.

The clue that this is the problem you're having is if one of your CPU cores pegs at 100% and your state doesn't apply in a reasonable amount of time (minutes, I guess).

Also you probably want to make sure you're not trying to use your large file as any sort of template. By default file.managed will assume no template, which is what you want for large files that aren't templates. I've never used large files which are templates, but I suspect if you tried that you'd have a bad time.