Tuesday, December 28, 2010

Another knock against the "Multitasking is good" argument

Doing several things at once is a trick we play on ourselves, thinking we're getting more done. In reality, our productivity goes down by as much as 40%. We don't actually multitask. We switch-task, rapidly shifting from one thing to another, interrupting ourselves unproductively, and losing time in the process.
No one is exempt from this, but some people are better at switch-tasking than others. For my part, I try to put my all into whatever I am doing, ergo I am a big proponent of single-tasking.

Thursday, December 16, 2010

The Chaos Monkey

One of the first systems our engineers built in AWS is called the Chaos Monkey. The Chaos Monkey’s job is to randomly kill instances and services within our architecture. If we aren’t constantly testing our ability to succeed despite failure, then it isn’t likely to work when it matters most – in the event of an unexpected outage.

Wednesday, December 15, 2010

Firefox's new Infallible memory allocators

When working on Windows, we were trained to write and test code under low memory conditions to ensure that code was resilient to allocation failures and the like. The question that always came up was, "What is the apt behavior when an allocation fails?"

Well, the good folks at Mozilla have given us one answer - crash.

How can memory allocation be infallible?

The term "infallible" means that your memory allocation request is guaranteed to succeed: your code can never see a failed request, and so doesn't need to check for failure.

Inside the allocation routine, the situation is different. Under extreme memory conditions, it's possible that the allocation will fail; however, the allocation routine will not, in this scenario, return to your code. Instead, the application will terminate. This should be rare, because the memory management system will do everything it can to find the memory you've asked for.

Choosing a memory allocator

As you write new code that needs to allocate memory, there are some simple rules to follow to help you decide whether to use a fallible or an infallible memory allocator:

If you're allocating what may be a large chunk of memory, you should allocate the memory fallibly (using moz_malloc() for example), and check the result to be sure it's not null. You should do this for large memory allocations because in extremely low memory conditions, as described in How can memory allocation be infallible?, the application may terminate if an infallible allocator can't find the memory you requested.

If you don't know whether or not the memory will be large, use the standard malloc() routine, which is currently fallible but will eventually become infallible. Be sure to check the result for null.

When instantiating objects, the new operator creates them infallibly by default. If you want to allocate them fallibly, use the syntax new (fallible_t()) Foo().
When in doubt, use the infallible allocator and don't null check.
Interesting concept in my opinion, as long as the application has a chance to log its state, failure code, and die "gracefully".