Only run at most 10 transformers at once in barback.

pkg/barback/lib/src/transform_node.dart

Index: pkg/barback/lib/src/transform_node.dart
diff --git a/pkg/barback/lib/src/transform_node.dart b/pkg/barback/lib/src/transform_node.dart
index 6df431540abf424db33bf94c2efa608a75a01b7e..0cfc508f1ed07fa2aa6d886d9beedb3bd482b335 100644
--- a/pkg/barback/lib/src/transform_node.dart
+++ b/pkg/barback/lib/src/transform_node.dart
@@ -125,7 +125,10 @@ class TransformNode {
     _inputSubscriptions.clear();
 
     _isDirty = false;
-    return transformer.apply(transform).catchError((error) {
+
+    return phase.cascade.graph.transformerPool.checkOut().then((item) {

[Alan Knight, 2013/10/23 00:24:06]

That seems like a rather awkward way to get to the pool

[nweiz, 2013/10/23 04:11:25]

I agree. I'm planning a refactor that will make the "vertical" dependencies
(e.g. PackageGraph <-> AssetCascade <-> Phase <-> TransformNode) in barback more
clear.

+      return transformer.apply(transform).whenComplete(item.release);

[Alan Knight, 2013/10/23 00:24:06]

Is it worth defining a pool API that automatically acquires and releases. e.g.
   transformerPool.withResource( (resource) => transformer.apply(transform));
?

Also, is it right that in this expression we have a transformerPool, but we
don't obtain the transformer, we already have it, and we don't use item other
than implicitly. It might make sense if we're just limiting the number running
at once, but just wanted to be sure.

[nweiz, 2013/10/23 04:11:25]

Done.
Yeah; really what the pool is controlling is calling [apply]. I'm going to
rename it to [transformPool] to make that a bit clearer.

+    }).catchError((error) {
       // If the transform became dirty while processing, ignore any errors from
       // it.
       if (_isDirty) return;