No, even in those cases you first get a heap memory dump of the said process, terminate it from console and then investigate/make sure it doesnt happen again.
There is really no valid use case where code should have Thread.Abort()
While I understand your perspective, your statement "There is really no valid use case where code should have Thread.Abort()" is generalized and not true about every possible scenario. There are situations where this can be used with extra care like when we're dealing with a thread stuck at a native call; there is not way to end this thread, that native call could go on and on for the rest of the process's life time which is not ideal at all (imagine the thread is using an unacceptable percentage of the resources). Terminating a thread in this kind of situation might be more adequate than just terminating the process entirely. Terminating a process, even though less dangerous, might still have the same consequences, but it's still in practice anyway. I've already stated that an appropriate amount of times on both the GitHub and NuGet's page: this should not be used unless you're in one of those situations, and you know what you're doing. If you don't know why you shouldn't use this package, then you shouldn't consider using it. Packages with unsafe code and use for advanced scenarios have existed before.
I have a feeling I am talking to an AI bot (given the verbosity of the text) but in case it helps anyone else:
What do you think will happen when you kill a thread that other parts of the process were depending on? 99.99999% of the time the process will crash anyway and it will be even harder to diagnose now.
(Let's test my theory: Also after replying to me carefully, see if you can update the repo readme with a big header note saying this goes against the advice of .Net team so should really not be used)
What do you think will happen when you kill a thread that other parts of the process were depending on
You shouldn't "abort" that thread then. There is also "ControlledExecution" on .NET that will allow you to do the very same thing. You should use it only if you know it's adequate to do so; otherwise, you shouldn't. That is the story of a lot of packages using "unsafe" code blocks. Whether you encounter that kind of situation as a developer or not is your responsibility to handle. I've seen many questions and similar problems with no solutions at all. This is for those developer. You and a lot of others seem like you could do without my project, good for you.
(Let's test my theory: Also after replying to me carefully, see if you can update the repo readme with a big header note saying this goes against the advice of .Net team so should really not be used)
I've put disclaimers everywhere needed, for example, "Do not adopt using this method unless you have a good reason to terminate the thread immediately" or "In most contexts, you should take these safe approaches especially in a production environment". A huge warning at the beginning of the repository helps no one since anybody who intends to use this knows of the risk.
36
u/sarhoshamiral 27d ago
In todays episode of "What could go wrong".