What does the DisposeAsync do in IAsyncEnumerable<T>

[John0King]

I have some code that read from some source and produce an IAsyncEnumerable<T>
but the problem is that I can not await foreach it, and can only called MoveNextAsync(), and as you know IAsyncEnumerable<T>.GetAsyncEnumerator() will get an new IAsyncEnumerator so earlier IAsyncEnumerator.DisposeAsync() may be called by the destructor via GC

private CancellationTokenSource CancellationTokenSource = new CancellationTokenSource();
IAsyncEnumerable<Memory<byte>> GetAsyncStream([EnumeratorCancellation] CancellationToken cancellationToken = default)
{
   while(true)
    {
      if (cancellationToken.IsCancellationRequested || CancellationTokenSource?.IsCancellationRequested == true)
        {
                   break;
        }

      var result = await source.Read();
    }
    source.Close();
}

and the caller is something like

async Task MethodA()
{
    var stream = GetAsyncStream();
    var itor = stream.GetAsyncEnumerator();
    await itor.MoveNextAsync();
    var result = itor.Current;
    // process result;
   // and do things with A conditaion

   //### should I called DisposeAsync() , and what it do in the `while(true)` loop inside `GetAsyncStream` method
}

async Task MethodB()
{
    var stream = GetAsyncStream();
    var itor = stream.GetAsyncEnumerator();
    await itor.MoveNextAsync();
    var result = itor.Current;
    // process result;
   // and do things with B conditaion
  
  ////### should I called DisposeAsync() , and what it do in the `while(true)` loop inside `GetAsyncStream` method
}

the problem

each method get an new IAsyncEnumerable<T> and it's IAsyncEnumerator or same IAsyncEnumerable<T> + multiple IAsyncEnumerator (concurrent is not the main issue, methodA and methodB will never handled concurrently). and what I want to do is that I'll not called source.Close() while the method (methodA methodB) executing. but even I do not call DisposeAsync manually , the GC + destructor may still call it anyway.

[Clockwork-Muse]

concurrent is not the main issue, methodA and methodB will never handled concurrently

Depending on a couple of factors, you might be in trouble just if calls to A and B are interleaved, even if not called "concurrently". In particular, if you're opening your source just once, but expecting both methods to read all elements, I get the feeling that's not happening.

but the problem is that I can not await foreach

... why? Not processing the entire contents of a collection is weird. You need to process the complete collection, in one of a few ways, but you haven't provided enough details to know what your actual problem is. In particular, if you get an enumerator, not disposing of it makes your program "poorly behaved" (in the, 'not acting to spec' sense).

IAsyncEnumerator.DisposeAsync() may be called by the destructor via GC

Some implementations may do this (eg, via a finalizer, but that's rare and possibly not a good idea), but the GC does not automatically handle this. Not knowing the lifetime of such a resource is a bug.

[John0King]

but expecting both methods to read all elements,

no, I do not expecting both of them read them, in fact, I need each method read it's own MoveNext value and each method moveNext just once.

the problem is I do not know what happened if the older IAsyncEnumerable been GCed, and which part of code been called when Disposing

[Clockwork-Muse]

Then it sounds like what you should do is create a methodC that collects two elements out of the collection and closes it, then passes them in to methodA and methodB as a parameter. Having any sort of call-order dependency between two methods is very brittle.

[John0King]

I don't find a solution for SemaphoreSlim in that way. Method A may SemaphoreSlim .WaitAsync() and insider calling into methodA_ping() -> methodA_waitPong(). and with a awiat foreach loop I can not control the MoveNext in that way. maybe I should just forgot IAsyncEnumerable and calling public result Read() mutiple times.

[ufcpp]

+ try {
   while(true)
    {
      if (cancellationToken.IsCancellationRequested || CancellationTokenSource?.IsCancellationRequested == true)
        {
                   break;
        }

      var result = await source.Read();
    }
-    source.Close();
+ } finally { source.Close(); }

[Clockwork-Muse]

Alas, the problem is far more fundamental. Part of the problem is that it's unclear whether the Close is even required at all.

[John0King]

I'd like to know witch part of code goes into the DisposeAsync

[huoyaoyuan]

You can check the code generation at https://sharplab.io/#v2:D4AQTAjAsAUCAMACEEAsBuWIDMyyIGFEBvWRc5XEADkQEkBBAZwE8A7AYwFE2BXAWwCmAJwCGAIwA2ggDwBLNgBcAfIgCyACgCUJMhX0oIyAOyIImGPoMQjIU2AtWKKAJzbHFAL6xPQA

The cleanup of the state machine goes into DisposeAsync. This will make a subsequent enumeration not allocating a new state machine.

[John0King]

The generated code it too hard to read 🤣, but it seems that DisposeAsync will do nothing for user's code, it just make the state machine as finished like the yield break, that means you can not calling into your "clearn up" code when DisposeAsync

but when you use try{} finally{} block to wrap your code, then the code in finally block will be called , so when you calling DisposeAsync , the code inside the finally block will be execute.

I wasn't try insider try-finally block yet, but it should only work for the top level finally block

[John0King]

@huoyaoyuan @ufcpp @Clockwork-Muse @frankbolero

The generated code it too hard to read 🤣, but it seems that DisposeAsync will do nothing for user's code, it just make the state machine as finished like the yield break, that means you can not calling into your "clearn up" code when DisposeAsync

but when you use try{} finally{} block to wrap your code, then the code in finally block will be called , so when you calling DisposeAsync , the code inside the finally block will be execute.

I wasn't try insider try-finally block yet, but it should only work for the top level finally block

in fact, DisposeAsync will calling into finally but With One Exception :

> it = g.GetAsyncEnumerator();
> it.MoveNextAsync()
[True]
> await it.DisposeAsync()
disposeing
> -----------------------------------
> it = g.GetAsyncEnumerator();
> await it.DisposeAsync()
> <nothing output>

that means ,

• the generated code does not contains code for destructor
• we should open the "source" when create our IAsyncEnumerable<T> , and use finally to dispose our "source"
• we should not dispose inside the "finally" block if we pass an opened "source"

and do not

• do not expect it always dispose your resource if you do not calling DisposeAsync
• do not expect it always dispose your resource if you do not calling MoveNextAsync() at least once