Feature Request: De-throttling for pipelines and/or collections.

[the-Arioch]

Making a demo got an app frozen at Pipeline.WaitFor

After a while I figured out the reason.
And I agree that for server0like application when first results should be yielded to client before the last item produced it makes little use.

Still I think that potentially blocking features should be made optional, at least on bailout terms.

So I ask for one of (or both) features:

1. iOmniPipeline.DeThrottle() procedure with the same use semantics as per .Throttle
2. iOmniBlockingCollection expanded with .WasAccessed function and .DeThrottle procedure so pipeline stages could do

if not output.WasAccessed() then output.DeThrottle()

This feature would perhaps be even more useful for self-re-fuelling pipelines when the same stage can be both producer and consumer, thus blocking itself on TryAdd would prevent further TryTake and cause self-deadlock..

• https://plus.google.com/+AriochThe/posts/LCHnSCmZYtx
• http://stackoverflow.com/questions/34958285/

Perhaps IOmniBlockingCollection.IsThrottlingEnabled() and IOmniBlockingCollection.IsThrottlingNow() might be of use too. So if a pipeline stage requires not-throttled collection and can no more change its mode it can explicitly raise exception