API proposal: Modern Timer API

[davidfowl]

To solve of the common issues with timers:

1. The fact that it always captures the execution context is problematic for certain long lived operations (https://github.com/dotnet/corefx/issues/32866)
2. The fact that is has strange rooting behavior based on the constructor used
3. The fact timer callbacks can overlap (https://github.com/dotnet/corefx/issues/39313)
4. The fact that timer callbacks aren't asynchronous which leads to people writing sync over async code

I propose we create a modern timer API based that basically solves all of these problems 😄 .

• This API only makes sense for timers that fire repeatedly, timers that fire once could be Task based (we already have Task.Delay for this)
• The timer will be paused while user code is executing and will resume the next period once it ends.
• The timer can be stopped using a CancellationToken provided to stop the enumeration.
• The execution context isn't captured.

+namespace System.Threading
+{
+   public class AsyncTimer : IDisposable, IAsyncDisposable
+   {
+        public AsyncTimer(TimeSpan period);
+        public ValueTask<bool> WaitForNextTickAsync(CancellationToken cancellationToken);
+        public void Stop();
+   }
+}

Usage:

class Program
{
    static async Task Main(string[] args)
    {
        var second = TimeSpan.FromSeconds(1);
        using var timer = new AsyncTimer(second);

        while (await timer.WaitForNextTickAsync())
        {
            Console.WriteLine($"Tick {DateTime.Now}")
        }
    }
}

public class WatchDog
{
    private CanceallationTokenSource _cts = new();
    private Task _timerTask;

    public void Start()
    {
        async Task DoStart()
        {
            try
            {
                await using var timer = new AsyncTimer(TimeSpan.FromSeconds(5));

                while (await timer.WaitForNextTickAsync(_cts.Token))
                {
                    await CheckPingAsync();
                }
            }
            catch (OperationCancelledException)
            {
            }
        }

        _timerTask = DoStart();
    }

    public async Task StopAsync()
    {
        _cts.Cancel();

        await _timerTask;

        _cts.Dispose();
    }
}

Risks

New Timer API, more choice, when to use over Task.Delay?

Alternatives

Alternative 1: IAsyncEnumerable

The issue with IAsyncEnumerable is that we don't have a non-generic version. In this case we don't need to return anything per iteration (the object here is basically void). There were also concerns raised around the fact that IAsyncEnumerable<T> is used for returning data and not so much for an async stream of events that don't have data.

public class Timer
{
+     public IAsyncEnumerable<object> Periodic(TimeSpan period);
}

class Program
{
    static async Task Main(string[] args)
    {
        var second = TimeSpan.FromSeconds(1);

        await foreach(var _ in Timer.Periodic(second))
        {
            Console.WriteLine($"Tick {DateTime.Now}")
        }
    }
}

Alternative 2: add methods to Timer

• Avoids a new type
• Confusing to think about what happens when WaitForNextTickAsync is called when a different constructor is called.

public class Timer
{
+     public Timer(TimeSpan period);
+     ValueTask<bool> WaitForNextTickAsync(CancellationToken cancellationToken);
}

cc @stephentoub

[natalie-o-perret]

I like the idea, but when it comes to stop the timer I found it a little bit weird (I mean I guess in your example, that would involve a break to get out of the foreach loop).

[davidfowl]

I like the idea, but when it comes to stop the timer I found it a little bit weird (I mean I guess in your example, that would involve a break to get out of the foreach loop).

Right, it's pull so you stop the timer by breaking out of the loop, or using a cancellation token with the IAsyncEnumerable to stop it from running (that also works if you're not directly in the loop).

[NtFreX]

public static class Timer
{
    public static async Task Subscribe(this IAsyncEnumerable<TimerSpan> ticker, Action<TimerSpan> action)
    {
        await foreach(var t in ticker)
        {
            action?.Invoke(t);
        }
    }
}

var second = TimeSpan.FromSeconds(1);
using(var ticker = Timer.CreateTimer(second, second))
{
    await ticker.Subscribe(t => Console.WriteLine($"Tick {t}"));
}

As long as we get some good helper methods simular to the one above I like fanciness.

[davidfowl]

The entire point of this is to avoid callbacks, but if you want to write that helper, have at it 😄

[NicolasDorier]

That is sexy. Though it is difficult to know from the look of it, what happen if a tick happen while we are not awaiting. Do they queue up so every tick will get served? or are they ignored if nobody here to listen to them?

[ankitbko]

public static class Timer
{
    public static async Task Subscribe(this IAsyncEnumerable<TimerSpan> ticker, Action<TimerSpan> action)
    {
        await foreach(var t in ticker)
        {
            action?.Invoke(t);
        }
    }
}

var second = TimeSpan.FromSeconds(1);
using(var ticker = Timer.CreateTimer(second, second))
{
    await ticker.Subscribe(t => Console.WriteLine($"Tick {t}"));
}

As long as we get some good helper methods simular to the one above I like fanciness.

Seems very similar to rx timer. Always felt rx should slowly integrate into coreclr/fx.

[willdean]

With apologies for the bike-shedding, but can I suggest it's called something other than Timer?

We already have these three famous ones:
System.Threading.Timer
System.Timers.Timer
System.Windows.Forms.Timer
Plus another few I didn't know about until I looked at Reference Source just now.

People don't always qualify which one they're talking about (#32866 is a good example), and adding another new one just makes things hard to learn for newcomers and hard to talk about.

If it was called Timer2020 then as long as there wasn't more than one new timer class added each year, that would be a scaleable naming scheme... (Not a serious suggestion, in case my audience is unappreciative.)

[svick]

public class Timer

I take it this is System.Threading.Timer, and not System.Timers.Timer, or some new namespace?

public static IAsyncEnumerable<TimerSpan> Create(TimeSpan dueTime, TimeSpan period);

Assuming this method is indeed added to System.Threading.Timer, I feel like calling it Create is not sufficient to differentiate it from the Timer constructor. Though I'm not sure what name would be better here.

---

In general, I agree that having await-based timer is useful, but I'm not sure IAsyncEnumerable<T> is the right abstraction for that.

For example, consider that I want to output items from a collection to the console, but only at a rate of one per second. With a different design, that could be easily achieved by something like:

using var timer = Timer.Create(TimeSpan.Zero, TimeSpan.FromSeconds(1));

foreach (var item in items)
{
    await timer.WaitForNext();
    
    Console.WriteLine(item);
}

But I think this would be much harder to write using an IAsyncEnumerable<T>-based timer, at least without Ix.NET.

[vshapenko]

Maybe this should be an extension to System.Threading.Channels?

[davidfowl]

@svick you can use IAsyncEnumerable for that as well. What you wrote is literally GetEnumerator + MoveNextAsync

[alefranz]

• If user code takes longer to run than the interval, we drop the tick events that happened until the user can catch up (think bounded channel with drop and a capacity of 1).

That's definitely the right approach, but I think it would be nice to customize what happens when a tick is missed: return immediately on await vs wait for the next tick (so to get back in sync)

[stephentoub]

Just to make sure I understand the proposal, you're basically proposing this, right? (I'm not sure what the TimeSpan is meant to be an offset from, so I've just used DateTime here.)

public static IAsyncEnumerable<DateTime> Create(TimeSpan dueTime, TimeSpan period)
{
    var c = Channel.CreateBounded<DateTime>(1);
    using (new Timer(s => ((Channel<DateTime>)s).Writer.TryWrite(DateTime.UtcNow), c, dueTime, period))
        await foreach (DateTime dt in c.Reader.ReadAllAsync())
            yield return dt;
}

?

[ankitbko]

If we are open for new name, I would propose Interval.

But adding something similar to Timer under new name smells bad. Creates unnecessary confusion.

[omariom]

Now we need this

IAsyncEnumerable<Message> channel = channelReader.ReadAllAsync();
IAsyncEnumerable<TimeSpan> ticker = Timer.CreateTimer(second, second);

(channel, ticker) switch 
{
    TimeSpan tick => 
    {
    },
    Message msg => 
    {
    }
}

I can't find @stephentoub's proposal on the subject 😐 but there was definitely one

[davidfowl]

@stephentoub Yep. But with BoundedChannelFullMode.DropOldest, though that really only matters if we find something useful to put in the <T>. Originally I was thinking time since last tick so if the code execution lasts longer than the period, you'd get a timespan that represnted how long between MoveNext calls but it was late, I dunno if that's useful 😄