Convert Task-based continuous services into Thread-based ones

[karashiiro]

Tasks are made for one-off actions. They are not made for continuously-running ones, because Tasks have no guarantees of when they will actually be executed. This problem is only exacerbated when the Tasks hog the underlying thread pool. This has been an issue during testing -- in loops where logging doesn't happen immediately, the loops rarely don't run.

or

STOP USING TaskS

• TaskS WERE NOT MEANT FOR CONTINUOUSLY-RUNNING ACTIONS
• YEARS OF ThreadPoolS BUT NO REAL-WORLD USE FOUND beyond running one-off actions
• Wanted to run continuous actions anyway for a laugh? We had a tool for that: It was called THREADS
• "Yes please Task.Factory.ContinueWhenAll. Please res.Content.ReadAsStringAsync().ConfigureAwait(false)" - Statements dreamed up by the utterly Deranged

LOOK at what Programmers have been demanding your Respect for all this time, with all the programming languages & concurrency primitives we built for them

(This is REAL Programming, done by REAL Programmers):

while (!token.IsCancellationRequested) 
{
    // ?????
}

while (true) 
{
    if (token.IsCancellationRequested)
        token.ThrowIfCancellationRequested();
    // ???????
}

while (!done)
{
    // ?????????????????
    if (token.IsCancellationRequested) throw new OperationCanceledException();
    await Task.WhenAll(_db.Users.Select(u => _client.GetUser(u.DiscordId)).Select(async user => await user.AddRoleAsync(guild.Roles.FirstOrDefault(r => r.Name == "tasks for brains"))));
    await Task.Delay(new TimeSpan(1, 0, 0));
}

They have played us for absolute fools

[karashiiro]

Memes aside, I'll just migrate to Quartz for this. I can use this for the announcement system as well, to clean it up a bit more.