Возможности COUNTER и реализация параллельно исполняемого кода.
Все мы знаем, что COUNTER выполняет код, помещённый на него, раз в пол секунды (опционально).
Меня давно терзает мысль, которую я никак не могу проверить (не доходят руки), и вопрос, который я всё время забываю задать, хотя ответ давно уже есть, и как минимум один человек на этом форуме может его дать.
Этот вопрос так же связан со способностью QSP к рекурсии (относительно).
А заключается он в следующем: вызывается ли COUNTER строго раз в пол секунды, независимо от того был выполнен на нём код, или вследующий раз он будет вызван не раньше, чем выполнится код первого вызова?
Хочу запихнуть в counter код, который должен выполняться параллельно с основным кодом (долгие процедуры генерации чего-либо, например). Будет ли подобное работать, и вообще, действительно ли counter работает “параллельно”?
вызывается ли COUNTER строго раз в пол секунды, независимо от того был выполнен на нём код, или в следующий раз он будет вызван не раньше, чем выполнится код первого вызова?
Второе.
…запихнуть в counter код, который должен выполняться параллельно с основным кодом (долгие процедуры генерации чего-либо, например). Будет ли подобное работать… ?
Не будет.
Aleks Versus,
принцип работы каунтера такой.
Представь, что интерпретатор QSP - это торговый киоск с маленьким окошком. В один момент времени может обслуживаться только один человек. Вот он подошёл, купил что-то и ушёл.
Каждый человек - это команда, отданная игроком. Покупка человека - это результат работы интерпретатора.
Вот игрок заходит на локацию A, в ларёк отправляется Локаций Петрович с заданием “зайти на локацию A”. Подходит к ларьку, ему выдают “описание теперь такое-то, действия в локации теперь такие-то”. Он ушёл, окошко свободно.
Пока Локаций Петрович стоит у окошка, подойти к окошку нельзя. Всем остальным приходится ждать своей очереди. В том порядке, в каком их отправили в ларёк.
Раз в час, к ларьку отправляется Каунтер Васильевич. Если очереди нет и окошко свободно, его сразу обслуживают. Если же окошко занято, он встаёт в конец очереди. Подходит его очередь - он покупает всё, что ему надо, и уходит до следующего часа.
Таким образом, все команды в интерпретаторе выполняются строго последовательно. Каунтер может начать свою обработку только при условии, что интерпретатор не занят обработкой другого кода. Соответственно, пока выполняется сам каунтер, никакой другой код не может “вмешаться”, до завершения обработки. Единственное, что у каунтера отличается - это вызов “по расписанию”, а не по команде игрока.
Ещё важный момент. Раз плеер недоступен для принятия команд от игрока во время обработки кода, то он логичным образом “блокирует” на этом время интерфейс. Пока выполняется хоть какой-то код, плеер блокируется. Это легко заметить при использовании оператора WAIT.
Единственное, что выполняется в плеере параллельно и независимо, это проигрывание музыки и звуков. Интерпретатор просто даёт короткую команду “играй такой-то файл”, а дальше проигрыванием уже занимается звуковая библиотека или сервисы операционной системы. И музыка играет, пока трек не закончится, либо интерпретатор очередным вызовом её не выключит.
Это очень жаль. Так я, собственно, и думал. Придётся оптимизироваться, что ж. :D