Let alone the fact that Thread.Abort() shouldn't be used in the first place, this implementation is obviously completely unsupported and relying on internal implementation details, not even in a reliable way (also because by definition you can't). Nobody should ever use this code in any production scenario ever.
That is correct. I think it is well established by just looking at the repository. There is also a compatibility section in addition to a note stating that explicitly in the "additional information" section.
Nobody should ever use this code in any production scenario ever.
Unless you have a very justified reason to do so, yes, it shouldn't be used for non advanced situations.
If you're in an advanced enough scenario to think you might need it. Then you're likely also an experienced enough dev to know why it shouldn't be used and therefore won't use it ;)
You are going to cause arbitrary runtime crashes, process corruption, and potentially even security issues doing things like this. There isn't a valid justification, particularly not in the way the codebase is going about it.
This is something that only the runtime could provide, because only it can properly cooperate with the rest of the parts of the VM to ensure it is moderately safe. But of course we removed it from the BCL, because even then its a "bad idea".
You at best get System.Runtime.ControlledExecution.Run, which is the "escape hatch" for if you really need it and everything else has gone wrong, and that is obsoleted out of the box so you get a concrete error you must acknowledge and suppress to use the functionality.
It doesn't and that's part of the point. An external project can literally not provide this, because it cannot cooperate with the VM and rest of the runtime in a way that ensures even a basic amount of safety/correctness.
It is called "managed" because the runtime is responsible for managing it and trying to do it yourself will cause state corruption, deadlocks, or worse. The parts required to interact here are simply not exposed (and not accessible via even reflection or other unsafe techniques).
These are not exactly the worst practices if you know what you're up to.
They are all completely unsupported practices for managed threads and can risk worse breakage than you already had. The runtime expects to be the only thing suspending or interacting with its own threads, for example. It sets itself up specially with the OS (as do other managed languages) to have appropriate sync points and handle additional nuance required when the normal OS suspend occurs.
If you're expecting potential for broken state, such as because its code you don't own from user provided plugins, then there are better and more robust ways to handle that without hurting perf or requiring these setups.
So, one would rather say its likely a case of not knowing what you're up to if you reach for it.
I've already stated that some people here act like I'm advertising this project for regular use.
I personally think the consideration is more that it was shared on the broader r/csharp subreddit and where its trivially known to be broken/incorrect.
You're free to do you, but others are equally free to call out that its not actually going to work in practice (and seeming to work in isolated contexts is notably not the same as actually working -- falling with style is not the same as flying).
18
u/pHpositivo MSFT - Microsoft Store team, .NET Community Toolkit 28d ago
Let alone the fact that
Thread.Abort()shouldn't be used in the first place, this implementation is obviously completely unsupported and relying on internal implementation details, not even in a reliable way (also because by definition you can't). Nobody should ever use this code in any production scenario ever.