Allow the timers created by TimeProvider to communicate if is resettable

[tarekgh]

This issue is to track address the comment on the PR.

TimeProvider allows creating a timer through the method CreateTimer. The created timer can be used in various places like in CancellationTokenSource which support operations like TryReset. Such operation is supported with the system timer only. This issue track looking at if we need to have such operations work with the custom timers too.

[ghost]

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

Issue Details

---

This issue is to track address the comment on the PR.

TimeProvider allows creating a timer through the method CreateTimer. The created timer can be used in various places like in CancellationTokenSource which support operations like TryReset. Such operation is supported with the system timer only. This issue track looking if we need to have such operations work with the custom timers too..

Author:	tarekgh
Assignees:	-
Labels:	area-System.Threading
Milestone:	-

[tarekgh]

CC @stephentoub

[tarekgh]

#36617

[stephentoub]

Right. We should double check, but I expect we could make this work if we add an out bool idle or something like that, which would be set to true iff both timeouts were infinite, the method returns true, and the implementation guarantees that the timer will not fire unless subsequent changes are made, eg there's no pending work item already queued that will invoke the timer's callback.

[tarekgh]

We'll watch if we find there will be any demand to support this issue and then we can consider it. Maybe in the future we can expose ITimer.MightHavePendingWork and have the timers implement it properly which can be used to address this issue. Closing it for now.