Dropn Fbombs
Dropn Fbombs

Reputation: 119

Threading with .Net Core

I'm trying to make a series of microservices and am currently working on a base class for them utilizing a .Net Core console app. The goal is to have the services, deployed as Docker containers, be able to monitor a source of information (Kafka, SQL, whatever) ,and then activate when they find their trigger. A dev should be able to just grab this base class and put their logic in place without having to worry about the logic triggering it or any other underlying service logic.

To do this I'm trying to utilize threading in the base class in a way that the user of the class doesn't have to deal with it but keeps the service responsive and able to monitor/respond to external commands (like the ability to get status, cancel a job, etc). Unfortunately it seems that Microsoft is trying to do away with System.Threading in .Net core, since I can start threads them but I can't stop them. This removes the ability to cancel/pause a job, which in turn removes the ability to shut down the service since I cannot stop the thread.

I've looked at Tasks, but they seem to be for web development. In fact most if not all information I've found about threading and microservices in .Net Core refers to making WebAPIs in ASP .Net. Other than that I really haven't found much information about how to use System.Threading now that every control other than .Start seems to have been removed.

I'm about to look at a system where I have the thread host a Task, then try using Task controls to see if I can cancel it and then have the thread just gracefully drop (similar to answer from here: dotnet core equivalent to Thread.Abort). This doesn't feel right, like I'm making a toothpick tower that can easily break, however I need to have the base service maintain control over the thread; I don't want myself or others to have to continuously check a token throughout their logic to see if the thread is supposed to be shut down.

Is there a better way of going about what I'm trying to do here? I've been looking for days but I keep running into the same stuff and it's all about how to make webapis utilizing Tasks, which is nothing like what I'm trying to do here; they pause the main logic rather than run independently. Guess it's an annoying bi-product of this "everything must be a website" frame of mind in the industry. Not sure if I'm missing something obvious by asking the wrong questions or if it's just going to be this odd of a job.

Upvotes: 0

Views: 10113

Answers (1)

Pac0
Pac0

Reputation: 23149

Task and await/async language features are a nice way to abstract threading, and are supposed to help exactly for what you wish for (keep the application responsive by using thread pool), whilst saving you the hassle of properly create and manage all those threads (not to mention catching exceptions during asynchronous execution).

As stated in comments, I think you should give it a try "properly" and then measure if it meets your performance objectives.

Some of the functions returning a Task return them "hot" (meaning, already executing their work). If you do not wish to "pause the Main flow", just do not await the Task returned until the end of your workflow. By the way, this should be the case when using Task.Run.

Sometimes, Task are "cold", and started automatically when await is called. But you can start them manually without awaiting them by using Task.Start.

Of course, using Tasks have it's pitfalls and you should should still be aware of what it does behind the scenes. You can still do "bad" thread programming things, for instance cause deadlocks in some situations, or fail to handle exceptions.

Further reading, picked up among many :

but there are many more.

Upvotes: 2

Related Questions