Failing to get a lock doesn't retry about node-tilejson

[yhahn]

Ugh, we should keep the locking IO but fix this. Want to add an additional test that has a failed load and demonstrates the problem?

https://github.com/mapbox/node-tilejson/blob/master/test/tilejson.test.js#L118

Then let's look into what's going on and fix.

[mikemorris]

@yhahn Interestingly, the locking IO seems to work just fine in a for loop, performing the file IO only once, but calling many callbacks. I was able to reproduce the issue using Step though https://github.com/mapbox/node-tilejson/blob/broken-locking/test/tilejson.test.js#L188-222

[mikemorris]

@yhahn "Fixed" in 4978876 by switching from EventEmitter to a simple array of callbacks and a while loop. I'm uncertain if this actually addresses the underlying problem, but all tests are passing now. My theory is that this problem was caused by relying on the many callback to move to the next step before deleting the lock, in which case a new many callback was added to the (still existing and locked) EventEmitter from the next step, and never executed because the EventEmitter then gets deleted afterwards. A race condition may still exist here (will the next callback always be added before the while loop exits?), would like to discuss how this should be handled correctly.

[yhahn]

O_o

Only small thing I would vet here is whether the callbacks should be called using pop() or shift(). I'm assuming the caller will expect the first callbacks added to be called first once the lock is release.

[mikemorris]

@yhahn Ack, yea good catch, shift() would probably make more sense here, done in 81de5f4