Cameron
It would be non-trivial to implement. See #53. There would also be extra overhead for every enqueue and dequeue operation.
Hmm, that's unfortunate. I'll try adding a try-catch around the encoding and see if the speed is impacted at all (probably not). Bugfix ETA: next 12 hours.
Good thing there's no rush, 'cause this is trickier to fix than I thought. There's [a bug in the compiler](http://code.google.com/p/haxe/issues/detail?id=480) with try-catch in inlined functions. So... I'm not sure what...
Would a `cancel()` method work? It's a lot easier to implement. There really is no internal (static) state beyond the "currently encoding" flag. All the state is in the object...
Nope, since that would be on the encoder object, which I don't have access to in the static function. (I could keep a static reference to the current encoder, but...
So it is! :-) But I realized that wouldn't work anyway, since you'd probably get many more exceptions between the time the error occurred and the time it's cancelled, on...
Indeed sounds similar to #271. Note that the call stack shown here is of a thread that's blocking (not consuming any CPU). `timed_wait` cannot deadlock, but it could wait indefinitely...
> @cameron314 maybe you should document in readme the case for short living threads. Definitely, slipped off my radar last time but I'll make sure to update it soon. The...
> Can you provide a size() function in moodycamel::ConcurrentQueue? No, though `size_approx()` should be fairly accurate most of the time (and completely accurate without contention).