Павел прав, когда говорит, что это плохая идея. Вы логически создаете ситуацию, когда действия в очереди могут привести к потере системных ресурсов. Вы даже можете обнаружить, что он работает на вашем компьютере, но не работает на компьютере клиента. Доступная память, 32- / 64-битный процессор и т. Д. Могут повлиять на код.
Однако ваш код легко изменить, чтобы он делал то, что вы хотите.
Сначала, однако, метод Timer
будет правильно планировать события таймера, пока наблюдатель заканчивает работу до следующего запланированного события. Если наблюдатель еще не закончил, таймер будет ждать. Помните, что наблюдаемые таймеры являются «холодными» наблюдаемыми, поэтому для каждого подписанного наблюдателя существует новый наблюдаемый таймер. Это отношения один-к-одному.
Это предотвращает непреднамеренное использование ресурсов таймером.
Таким образом, поскольку ваш код в настоящее время определен, OnNext
вызывается каждые 1000 миллисекунд, а не каждые 100.
Теперь, чтобы код выполнялся с интервалом в 100 миллисекунд, сделайте следующее:
Observable
.Timer(TimeSpan.Zero, TimeSpan.FromMilliseconds(100))
.Select(x => Scheduler.NewThread.Schedule(() =>
{
count++;
Thread.Sleep(TimeSpan.FromMilliseconds(1000));
}))
.Subscribe(x => { });
Фактически этот код представляет собой IObservable<IDisposable>
, где каждое одноразовое использование - это запланированное действие, выполнение которого занимает 1000 миллисекунд.
В моих тестах это работало хорошо и увеличивало счет правильно.
Я попытался использовать свои ресурсы и обнаружил, что, установив таймер на запуск раз в миллисекунду, я быстро получил System.OutOfMemoryException
, но обнаружил, что код запускается, если я изменяю настройку на каждые две миллисекунды. Это, однако, использовало более 500 МБ ОЗУ, в то время как код работал и создал около 500 новых потоков. Совсем не красиво.
Действуйте осторожно!