Proposal: ChannelReader<T>.TryPeek

[stephentoub]

Per comment at https://github.com/dotnet/corefx/issues/41819#issuecomment-542819724, we should consider adding:

namespace System.Threading.Channels
{
    public abstract partial class ChannelReader<T> // existing class
    {
        public virtual bool TryPeek([MaybeNullWhen(false)] out T item) // new virtual method
        {
            item = default!;
            return false;
        }
        ...
    }
}

We'd need to confirm, but I believe it should be possible to override this with a valid implementation on all of the built-in channel implementations.

NOTE: Now that we have a {Can}Count property, it's quite possible for Count to return non-zero value but TryPeek to not be overridden and return false.

[terrajobst]

Video

• We should add a virtual CanPeek that returns false
• We'll want more feedback so we should punt this to .NET 6.

namespace System.Threading.Channels
{
    public abstract partial class ChannelReader<T>
    {
        public virtual bool CanPeek => false;

        public virtual bool TryPeek([MaybeNullWhen(false)] out T item)
        {
            item = default!;
            return false;
        }
    }
}

[KevinCathcart]

Was the conclusion that this should return false in the not CanPeek scenario? I just watched the video, and was left the feeling that throwing was still desired if not CanPeek. Which is not what the approved API summary is showing. But perhaps I missed something.

[Dean-NC]

I need this. I'm using channels for the first time, and I assumed it would be available on the reader since ConcurrentQueue<> has TryPeek. I have an API that receives "file changed" requests, where the caller lets me know 1 or more files from a CRM service changed and provides download URLs. The API controller queues them up and gives an acknowledgment back to the caller. A hosted BackgroundService in my API reads the queue and uploads them to a document archive web service.

Before removing an item from the queue, I'd like to know I uploaded the files for that request successfully, then de-queue. Since the BackgroundService is the only thing in my API that reads the queue, I'm not worried about other threads processing the same item.

I was going to use ConcurrentQueue but then I remembered Channels, and decided to use them.

[Dean-NC]

@stephentoub Thanks for doing this!! I'm looking forward to this feature in 6.0!