35 Replies
It doesn't seem like something that'd need to be done asynchronously
yes
is for forms
Even more of a reason to not do it asynchronously, then
why
then i get stuck on form app while hashing
and set as no responding
Ah, I see what you mean
yes
And what's the error?
System.Security.Cryptography on framework doenst have thath funcion
:D
So there's only a synchronous version of this method, then
i could downooad the package thath uses net for thath
Idk, try
Task.Run()?
https://learn.microsoft.com/pl-pl/dotnet/api/system.threading.tasks.task.run?view=net-7.0
Just don't do what they did in the docs, the .Wait() thing
await it properlyand i can get the result?
You should be able to, yes
Angius#1586
REPL Result: Success
Result: int
Compile: 600.086ms | Execution: 85.131ms | React with ❌ to remove this embed.
As demonstrated
so
byte[] UnpatchedFileHash = await Task.Run(() => DigestAlgorithm.ComputeHash(FileBufferStream));
interesting
sometimes i am very dumb
It is synchronous tho
amm
what
what does computehash return?
it is, but they're using Task.Run to offload the work from the UI thread
so it doesn't block the UI
Don't use Task.Run if the hash function runs for more than like 100 ms
It isn't designed for long-running operations
Putting synchronous code in an async fashion does not make it run asynchronously
If DigestAlgorithm.ComputeHash is synchronous, running it as a task will be synchronous.
That’s not how it works
Tasks are ran on the main thread in a thread pool. While the synchronous code in an async function is running, execution on the main thread is blocked.
Async only helps when there is actual async functions within a Task
await Task.Run(() => sync code here) waits asynchronously for the Task returned by Run to finish
yes, the work being done is sync, not async, but the important thing is the calling thread (the UI thread in this case) is not blocked
that's what I meant by "offload from the UI thread"
I'm also not sure what you mean by "Tasks are ran on the main thread in a thread pool"
the thread pool doesn't have a "main thread"
afaikah yeah you're right
that thought slipped my mind
I never realized Task.Run was fundamentally different to awaiting a Task.
why not, the thread pool automatically adjusts
itll create a new thread
When you await a task normally, it’s ran on the UI thread, or whatever synchronization context you’re calling from
the continuation after the first await will be scheduled by the sync context
No. Tasks don't run
Not necessarily
The thread pool can be starved of all threads if you perform too many long running operations
but it can create more threads
and it probably will
It responds pretty quickly. Especially in a desktop app, there won't be any problems sticking the odd long-running operation onto it, in practice
Heck, I've abused it to the point of it needing to scale up to 10,000 threads before
define "too many"
and we're talking a typical desktop app here
it's probably not going to hit "too many"
it's not
Task.Run just queues the delegate it's given to the thread pool
the return task completes when that work completes
no true either
I think you should read $nothread
it's about async IO, but provides a good general overview
There Is No Thread
This is an essential truth of async in its purest form: There is no thread.
a byte of the hash
omg guys
@Angius was right thath solved my problem
thanks all