I programed a FastCGI library for C#. This was before the time of async/await. Now I'm programming a version 2 of this library with performance in mind. Therefore i'm using IOCP by using socket.ReceiveAsync. (Note: ReceiveAsync has nothing to do with await/async. I want to use ReceiveAsync.)
However it is possible for the user of the library to answer an incoming request by not specifying Content-Length-header. This leads to a situation where the library needs to collect all outgoing traffic until all data are available or the user specifies Content-Length.
My old version of this library realized this with a self-written class LocalPipe. LocalPipe is just a Stream where you can write datas to and then read datas from it. If there are not enough datas available the read-method is blocking.
While LocalPipe is blocking the calling thread is also blocking and therefore not released while waiting for new data. This leads to a "one connection/one thread" design, at least while waiting for data from LocalPipe.
My question is: Is there already a class (as NuGet package or in the .NET framework itself) which implements something like my LocalPipe class but which will "block" without keeping the calling thread in use?
I'm not in search of the regular Task-Pattern for await unless it really would avoid the use of unnecessary Threads/Tasks and context-switches. Currently the only way to implement this class "thread consuming friendly" seems to make heavy use of ExecutionContext and/or SynchronizationContext while implementing an awaitable pattern by my self. It would be nice if I can just evade this.