C#•2y ago

any benefit to async?

What's the benefit of async code? I see lots of examples that await on all the async calls. A prominent example at hand is the XmlReader example here: https://learn.microsoft.com/en-us/dotnet/api/system.xml.xmlreader?redirectedfrom=MSDN&view=net-6.0 Since every call to ReadAsyc() is going to block on await, then what's the point of using async reads?

XmlReader Class (System.Xml)

Represents a reader that provides fast, noncached, forward-only access to XML data.

76 Replies

sibber•2y ago

it doesnt block on await thats the point

Omar•2y ago

Interesting. Then how does that loop work?

sibber•2y ago

it returns the context to the caller while awaiting, then returns when the task done

Omar•2y ago

The context? The next thing the caller does is examine an attribute of reader that isn't available until the completion of the async operation.

sibber•2y ago

meaning execution in the caller is continued unless the caller is also awaiting then execution will continue in its caller

Omar•2y ago

What does ReadAsync() return?

x0rld•2y ago

in general you don't want use async in a classic loop i don't understand why it's the case in this example 🤔

sibber•2y ago

async methods that are awaitable return a task why is that?

Omar•2y ago

Yep. Here, the task wraps a bool, which indicates if the next element was read from the XmlStream. How can execution continue in the caller if the result of the read operation isn't complete? Since the read operation isn't complete, how can reader.Name be evaluated? The implementation of XmlReader.Name will throw, in fact, if there's an outstanding read operation:

        public override string Name
        {
            get
            {
                CheckAsync();
                return _coreReader.Name;
            }
        }

        private void CheckAsync()
        {
            if (!_lastTask.IsCompleted)
            {
                throw new InvalidOperationException(SR.Xml_AsyncIsRunningException);
            }
        }

        public override string Name
        {
            get
            {
                CheckAsync();
                return _coreReader.Name;
            }
        }

        private void CheckAsync()
        {
            if (!_lastTask.IsCompleted)
            {
                throw new InvalidOperationException(SR.Xml_AsyncIsRunningException);
            }
        }

blinkbat•2y ago

async getters aren't a good usecase

Omar•2y ago

So I can't figure out how the caller continues without the operation being completed. Are you sure that await doesn't block until the returned Task<bool> is signaled?

blinkbat•2y ago

async works best in methods / is clearest

Omar•2y ago

The docs say this:

The await operator suspends evaluation of the enclosing async method until the asynchronous operation represented by its operand completes.

Is "suspends evaluation" somehow different than "blocks"?

blinkbat•2y ago

yes very different other ops can keep running

Omar•2y ago

In that example, what other operation would run?

blinkbat•2y ago

simple example

static void Main() 
{
  SomeAsyncTask();
  SomeVoid();  
}

public async Task SomeAsyncTask()
{
  var response = await // http request
  Console.WriteLine(response);
}

static void Main() 
{
  SomeAsyncTask();
  SomeVoid();  
}

public async Task SomeAsyncTask()
{
  var response = await // http request
  Console.WriteLine(response);
}

AsyncTask will start, then begin to await. SomeVoid can run. when response comes back, AsyncTask will keep going (write out, here) makes sense?

Omar•2y ago

That example is unlike the documentation example. In your example, there is no data dependency.

blinkbat•2y ago

a getter just seems like a weird use the idea of a getter is you need it available when you call for it

blinkbat•2y ago

https://blog.stephencleary.com/2013/01/async-oop-3-properties.html

Async OOP 3: Properties

Unlike async constructors, async properties could be added to the language without much difficulty (well, property getters could, at least). Properties are just syntactic sugar for getter and setter methods, and it wouldn’t be a huge leap to make these methods async. However, async properties are not allowed.

Omar•2y ago

.NET isn't using itself correctly?

blinkbat•2y ago

idk. does their example work?

sibber•2y ago

wdym

blinkbat•2y ago

he's looking @ official docs

sibber•2y ago

and why does he think theyre not correct?

Omar•2y ago

It works, but I don't see the benefit of using ReadAsync() when the result is awaited in a loop. An async method should run concurrently without blocking, but await causes a block.

sibber•2y ago

async != concurrency the purpose of async is to not waste resources waiting while doing nothing

Omar•2y ago

In the given example, what is being done while waiting?

sibber•2y ago

an example is a gui app a gui app needs to constantly check for input lets say you want to make a request to some api

Omar•2y ago

If a getter is a "weird use", then why is .NET written using getters?

sibber•2y ago

if you make the request synchronously on the main thread, the app will not check for input, and will wait until the request is finished and a response is returned, thus freezing

Omar•2y ago

So async is only useful when there's other work to do? Here, that would mean this example function directly has no benefit. Instead, the benefit is to the caller of the example function, assuming it has something else to do.

sibber•2y ago

with async, when you await the method that makes the request, the app will return to checking for inputs until a response is recieved, thus not freezing yes you cant await in getters

Omar•2y ago

Nobody's doing that.

blinkbat•2y ago

bc they're obsessed with getters lol idrk

Omar•2y ago

What is "idrk"? I'm writing an application that reads XML from a file, and inserts it to a database. The app is multi-threaded.

sibber•2y ago

what did you mean then? a weird use case for what?

Omar•2y ago

It seems that I won't benefit from using async in this application. I'm trying to understand this comment: https://discord.com/channels/143867839282020352/1030888721274376302/1030892373351354470

MODiX•2y ago

blinkbat#2238

a getter just seems like a weird use

Quoted by

<@!392025167859154947> from #any benefit to async? (click here)

React with ❌ to remove this embed.

sibber•2y ago

properties are the convention to expose fields in c#

Omar•2y ago

I'm well-aware of that.

sibber•2y ago

well im not sure what they meant

Omar•2y ago

Me, neither. That's why I'm asking.

blinkbat•2y ago

i agree with the article i sent, that an async property should be a method call typically and i'd need to see a corner-case otherwise

sibber•2y ago

an async property isnt a thing

Omar•2y ago

I can't find any async properties here.

blinkbat•2y ago

It is possible to have a property return a Task<T> just by returning the result of an async method: If every access to a property is going to kick off a new asynchronous operation, then that “property” should really be a method:

this way of thinking is clearer to me

Omar•2y ago

My app will read a record from XML, then dispatch it to a thread for insertion. Using ReadAsync() to read the XML won't help my app.

blinkbat•2y ago

i know your example doens't use the async return

Kouhai•2y ago

It'll help if you don't want your UI thread to be blocked

Omar•2y ago

It's a console application; there is no UI thread and no message pump.

Kouhai•2y ago

In that case, I guess not using Async is okay

Omar•2y ago

Is there a way to definitively know?

Kouhai•2y ago

Know what? That Async wouldn't be required?

Omar•2y ago

That it wouldn't be beneficial, yes.

sibber•2y ago

what are you doing on your other thread?

Omar•2y ago

Database inserts. The application's main thread reads from XML, then enqueues work items to threads which insert to the database.

sibber•2y ago

you dont need another thread for that

Omar•2y ago

I originally wrote this app more than 15 years ago, long before async was available.

sibber•2y ago

Kouhai•2y ago

If there is no UI updates, and no user input. Then not using Async is okay

blinkbat•2y ago

on the off chance your CLI allows users to do multiple read/writes at once each of those could be async calls so they don't block each other and are free to return at their earliest convenience that's really the only benefit of async

Omar•2y ago

On each of those ... what?

blinkbat•2y ago

operations that would otherwise block it sounds like you're using threading to do just that

Omar•2y ago

I'm afraid I'm not following you. There's 100% chance chat concurrent reads and writes are being done. There are multiple database connections.

blinkbat•2y ago

sure

Omar•2y ago

The XML reader produces a queue of records to be inserted. The queue is serviced by the threads, which pick a record off the queue and service it by performing the database work.

blinkbat•2y ago

is adding to the queue a blocking op? and would a user want to hit 'add' and then immediately move on to another

Omar•2y ago

Yes, because the queue implements backpressure. If too many elements are queued, then they'd just keep eating memory and run away.

blinkbat•2y ago

just trying to understand the problem domain

Omar•2y ago

It's just an ETL app. The queue also blocks to safely be consistent with concurrent readers and writers.

blinkbat•2y ago

i mainly use async/await for firing http on the frontend so this isn't my usage or occasionally waiting for renders or other long-running ops but it seems like to check the queue for safely adding you need it to block for a time anyway i can't think of a way aroudn that unless a user hits 'add' and then some time later a message comes back like 'add 123 failed' which is annoying might as well have just waited for the safety check

Unknown User•2y ago

Message Not Public

Omar•2y ago

The user isn't hitting anything. The app starts and begins reading the XML file. Aside from the command line, the only UI is output to the console showing progress. Or errors (if it's a bad day). Adding to the queue is protected by a lock block. The time this lock is held is minimal; just a call to Add() or Remove() on a collection.

blinkbat•2y ago

right doesn't seem like async would benefit this

Omar•2y ago

OK. Thanks for walking me through it!

blinkbat•2y ago

no worries it was interesting

Gaming

Programming

any benefit to async?