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
it doesnt block on await
thats the point
Interesting. Then how does that loop work?
it returns the context to the caller while awaiting, then returns when the task done
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.meaning execution in the caller is continued
unless the caller is also awaiting then execution will continue in its caller
What does
ReadAsync() return?in general you don't want use async in a classic loop i don't understand why it's the case in this example 🤔
async methods that are awaitable return a task
why is that?
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:
async getters aren't a good usecase
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?async works best in methods
/ is clearest
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"?
yes
very different
other ops can keep running
In that example, what other operation would run?
simple example
AsyncTask will start, then begin to await.
SomeVoid can run.
when response comes back, AsyncTask will keep going (write out, here)
makes sense?
That example is unlike the documentation example. In your example, there is no data dependency.
a getter just seems like a weird use
the idea of a getter is you need it available when you call for it
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.
.NET isn't using itself correctly?
idk. does their example work?
wdym
he's looking @ official docs
and why does he think theyre not correct?
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.
async != concurrency
the purpose of async is to not waste resources
waiting while doing nothing
In the given example, what is being done while waiting?
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
If a getter is a "weird use", then why is .NET written using getters?
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
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.
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
Nobody's doing that.
bc they're obsessed with getters lol
idrk
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.
what did you mean then?
a weird use case for what?
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
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.
properties are the convention to expose fields in c#
I'm well-aware of that.
well im not sure what they meant
Me, neither. That's why I'm asking.
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
an async property isnt a thing
I can't find any async properties here.
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
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.
i know your example doens't use the async return
It'll help if you don't want your UI thread to be blocked
It's a console application; there is no UI thread and no message pump.
In that case, I guess not using Async is okay
Is there a way to definitively know?
Know what? That Async wouldn't be required?
That it wouldn't be beneficial, yes.
what are you doing on your other thread?
Database inserts. The application's main thread reads from XML, then enqueues work items to threads which insert to the database.
you dont need another thread for that
I originally wrote this app more than 15 years ago, long before
async was available.ah
If there is no UI updates, and no user input. Then not using Async is okay
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
On each of those ... what?
operations that would otherwise block
it sounds like you're using threading to do just that
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.
sure
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.
is adding to the queue a blocking op?
and would a user want to hit 'add' and then immediately move on to another
Yes, because the queue implements backpressure. If too many elements are queued, then they'd just keep eating memory and run away.
just trying to understand the problem domain
It's just an ETL app.
The queue also blocks to safely be consistent with concurrent readers and writers.
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•3y ago
Message Not Public
Sign In & Join Server To View
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.right
doesn't seem like async would benefit this
OK. Thanks for walking me through it!
no worries it was interesting