Использование задержки (TimeSpan) или Thread.Sleep не работает должным образом в VMware - PullRequest
Новая
       107

Использование задержки (TimeSpan) или Thread.Sleep не работает должным образом в VMware

1 голос
/ 03 февраля 2020

Я свел свою проблему к этому примеру: 

[STAThread]
static void Main() {
   var t = Task.Run(async delegate {
      await Task.Delay(TimeSpan.FromSeconds(5));
      return "delayed action";
   });

   t.Wait();
   Console.WriteLine("Task t Status: {0}, Result: {1}", t.Status, t.Result);
}

Хотя на моем хосте P C это работает нормально, оно закрывается перед возвратом "отложенного действия" при запуске на VMware Workstation Player 15 с fre sh Windows 10 установка. Там нет ошибок. Если я добавлю еще один Console.WriteLine в начале, он будет показан в cmd. Я назначил на VMware 4 ядра и 6 ГБ памяти, виртуализация процессора отключена, ускорение 3d включено. Я пропускаю некоторые зависимости, или VM нуждается в другой конфигурации?

Моя цель состояла в том, чтобы создать серию SendInput функций, которые необходимо распределить по времени. Я даже попробовал сторонний инструмент «кликера», у которого есть опция задержки, и у него та же проблема. Я должен был установить его на 30 мс, чтобы получить клики на аппарате на 500 мс, как будто большая часть кликов никогда не регистрировалась. То же самое с моим кодом не работает на ВМ, но работает нормально на хосте P C.

1 Ответ

1 голос
/ 03 февраля 2020

К сожалению, я не могу помочь вам с исправлением конца VMWare, если не считать двух идей:

  • Если есть что-то, что проходит через потоки непосредственно в центральный процессор, вы можете попробовать выключая их. Это было бы плохо для производительности, но могло бы избежать проблем с Thread (Manager) и запуском ОС, работающей на несколько разных часах.

  • У меня есть другой подход, который вы могли бы попробовать. Тот, который намного меньше полагается на Thread / Asyn c и подобные системы задержки. Что-то, что может быть немного более устойчивым, против всего, что вызывает это Это различие было чисто случайно - оно начало свою работу в качестве примера для очень простой c системы ограничения скорости, которая будет работать в отдельном потоке:

    целочисленный интервал = 20; DateTime dueTime = DateTime.Now.AddMillisconds (интервал);

    while (true) {if (DateTime.Now> = dueTime) {// вставьте код сюда 

    //Update next dueTime
dueTime = DateTime.Now.AddMillisconds(interval);

    } else { // Просто уступим, чтобы не облагать налогом процессор CPU.Sleep (1); }}

В этом механизме потока используется только часть «низкая загрузка ЦП во время простоя». Все остальное основано на, возможно, более стабильной системе DateTime.

Обратите внимание, что короткие Intervalls плохо поддерживаются, даже 20 мс могут быть уже вне предела. DateTime.Now () не так удаленно точен, как тип может быть точным , поэтому он дистанционно работает только для двойных или тройных ди git интервалов. Задержка и сон действительно поддерживают точность в миллисекундах.

...