Last week I came across a new problem that took me a while before I was able to solve it and I want to share my experience with you.
The ...
For further actions, you may consider blocking this person and/or reporting abuse
If you don't mind me asking, why aren't you using Tasks?
I was using Tasks but then i read this Async Guidance from .Net Core team github.com/davidfowl/AspNetCoreDia... and refactored my code.
Ah great advice there.
Just stumbled about,
If I interpret it correctly, starting a task with LongRunning flag will just do the same, create a new thread.
May be this is different in .NET Core - but will be then also apply to .NET 5.0
Link to the source code below.
BR Andre
github.com/dotnet/runtime/blob/851...
Sorry, I dont understand, if you need to wait for each method, why are you creating threads?
My thought exactly, I could understand if it was a UI app and he didn't want to block the UI thread, but it's a console app...
Seems like a classic case of over engineering, but I am welcome to any explanation of course.
Hi @lordwabbit actually the main thread of the console is listening to a queue and based on some conditions it create jobs that need to be executed in a sequential order. The only way I could know that a job was finished was listening on the JobFinished event. That is the reason I used ManualResetEventSlim and Background Threads for the process.
I can agree that the example was not very successful since I could not reproduce the whole real life case I dealt with.
I am always open for suggestions :)
But everything is sequential. You wait for input, determine if it should be processed, create a series of tasks to perform which need to be executed in order, and then execute them in order. The creation of threads just complicates the process with absolutely no benefit. It's not even taking advantage of multiple CPU's. If you were going to execute entire sets of jobs at the same time from the queue then the threading would need to be higher in the architecture. But I suppose if it was just to test some proof of concept code then it doesn't really matter. I would just like to mention that the reason I even brought it up is that I have a horrible habit of over engineering, so I tend to keep an eye out for it in my own code. Sometimes KISS is actually better.
The point of the article isn't to solve every instantiation of this problem. He intentionally slimmed down his class so that you can see the pattern and determine whether you should use the same pattern in your own use case.
Thanks @rickystam , I have a UI app where I am implementing it successfully. :)
I am really happy I could help :)
This saved my solution. Thank you.
I'm glad you found this helpful :)