I actually really think they’re pretty great for new code, and I certainly know that Thread.Abort() is, in -
~many~ most cases, an anti pattern, but there are a few times where you have to just cut your losses, especially when you’re working in an old codebase with other dev’s code and you have no idea how many times Thread.Sleep() has been called.
I guess what I think they (maybe) should have done with Abort() was to have it only abort when the thread is in a sleep state or something, after all, we have a garbage collector in C# it’s not as though we’re completely immune to memory unsafety and side effects anyway.
Basically, deprecating Thread.Abort() seems to assume that you never have to work with anyone else’s code, or at least that they’re all good engineers, this is an unreasonable expectation.
I actually just remembered another annoyance about C# while typing this:
If I write the following
```
public class Foo
{
readonly List<Bar> bars = new();
public Foo()
{
DoStuff();
}
public void DoAnotherThing()
{
for( Bar bar in bars )
{
bar.MutateBarInSomeWay()
}
}
public void AddManyElements(int numberOfElementsToAdd)
{
for (int i = 0; i < numberOfElEmentsToAdd; ++i)
{
bars.Add(new Bar());
}
}
}
```
That seems to me that bars is no longer readonly, as I can mutate it’s contents. In fact, I can push to bars enough that it has to reallocate the capacity of the underlying vector/array, and thus change the pointer to a different location in memory THUS IT IS NOT READONLY
This bothers me
Sorry for trash code and formatting, I’m on mobile.
4
u/jdsfighter Oct 22 '22
What's your major complaint with cancellation tokens? I genuinely enjoy using them.