А если во время обработки массива циклом в конец добавится новый элемент, цикл захватит его тоже?
]]>Если принимающий скрипт начнет обрабатывать один запрос, а в этот момент придет другой - обработка первого прервется? А если не прервется, то как заставить скрипт оставить на потом следующий и начать обрабатывать его после обработки предыдущего?
Если во время обработки приходят новые данные, обработка прервётся, просто добавьте новое в конец массива, это не долго, и прерванная обработка массива запросов продолжится дальше с того же места где была прервана. Ничего сложного.
]]>Появился вопрос по указанной функции. Когда я забираю обновления из телеграма, мой скрипт аккуратно складывает все сообщения в массив и обрабатывает их циклом по очереди. Здесь, как я понял, так не получится, либо я не понимаю, как это сделать.
Если принимающий скрипт начнет обрабатывать один запрос, а в этот момент придет другой - обработка первого прервется? А если не прервется, то как заставить скрипт оставить на потом следующий и начать обрабатывать его после обработки предыдущего?
]]>Спасибо, думаю, это то, что нужно. Идею вроде понял, пытаюсь осуществить, но пока не до конца понял механизм работы.
http://forum.script-coding.com/viewtopic.php?id=15689
Там указано два потока, но можно и больше сделать.
Я почитал этот топик перед созданием своего, но для меня код оказался сложноват, я не смогу его ни полноценно использовать, ни как-то подстроить под себя.
Прошу прощения за, возможно, не к месту сказанное.
Предлагаю рассмотреть решение на Python 3.7+.
Это типичная I/O-bound задача и как оказалось, асинхронный интерфейс современного Питона справляется с этим идеально. Дело в том, что порождаемые корутины и таски запускаются в одном цикле событий, а значит у них общая память и не нужны все эти пляски с SharedMemory, отправкой сообщений и прочее. Просто пишете асинхронный код, который(в отличие от асинхронного JavaScript) выглядит, как синхронный и это работает.Было дело, тоже встала острая нужда в большом количестве обработки ввода/вывода и на AHK, в принципе можно оседлать эту затею, но чем больше в эти рамки пытаешься запихнуть, тем больнее когда падает фрагментированное по инстансам приложение.
AHK невероятно удобен и соблазняет собой решать абсолютно всё, но к сожалению, именно для этого типа задач он приспособлен плохо.
Да, это определённо про то, чтобы узнать что-то новое, но это новое как глоток свежего воздуха. Весь стейт в одном процессе. Работает так, будто каждый I/O-вызов обрабатывается в отдельном потоке, но при этом нет блокировок, накладных расходов связанных с менеджментом памяти, когда надо описывать "семафоры", "мьютексы" и прочие механизмы, в понимании которых и разбираться не охота. Просто пишешь логику, основанную на состоянии. Творишь! Остальное делает Python.
Про переход на другой язык мне уже неоднократно говорили, но да, как написано, этот совет про прыжок во что-то новое. У меня нет технического образования, это хобби, поэтому вряд ли хватит усидчивости и времени на изучение новых дисциплин. Но ощущение того, что пишу бота из палок и трамвайной ручки не отпускает.
Всем спасибо за ответы
]]>Предлагаю рассмотреть решение на Python 3.7+.
Это типичная I/O-bound задача и как оказалось, асинхронный интерфейс современного Питона справляется с этим идеально. Дело в том, что порождаемые корутины и таски запускаются в одном цикле событий, а значит у них общая память и не нужны все эти пляски с SharedMemory, отправкой сообщений и прочее. Просто пишете асинхронный код, который(в отличие от асинхронного JavaScript) выглядит, как синхронный и это работает.
Было дело, тоже встала острая нужда в большом количестве обработки ввода/вывода и на AHK, в принципе можно оседлать эту затею, но чем больше в эти рамки пытаешься запихнуть, тем больнее когда падает фрагментированное по инстансам приложение.
AHK невероятно удобен и соблазняет собой решать абсолютно всё, но к сожалению, именно для этого типа задач он приспособлен плохо.
Да, это определённо про то, чтобы узнать что-то новое, но это новое как глоток свежего воздуха. Весь стейт в одном процессе. Работает так, будто каждый I/O-вызов обрабатывается в отдельном потоке, но при этом нет блокировок, накладных расходов связанных с менеджментом памяти, когда надо описывать "семафоры", "мьютексы" и прочие механизмы, в понимании которых и разбираться не охота. Просто пишешь логику, основанную на состоянии. Творишь! Остальное делает Python.
]]>Добрые люди мне посоветовали разделить бота на сервисы, то есть чтобы разные команды, игры и функции выполняли разные скрипты в разных потоках, и это решение меня устраивает. Очередь обработки на игру лучше, чем очередь обработки абсолютно всех запросов. И вопрос - как это сделать?
База данных в INI файлах в папке, все работает довольно быстро. Скрипт каждые 100 мс собирает апдейты с телеграма, складывает их в массив, затем преобразует JSON объекты в понятные для AHK и уже обрабатывает. Как я понимаю, можно запустить несколько скриптов: обработка главного меню и обработка для каждой из 4 доступных игр (всего 5).
Получается, должен быть главный скрипт, который будет собирать апдейты и посылать их нужным скриптам на обработку. В каком виде их посылать? Получается тут вопрос реализации бесперебойного сообщения JSON-объектов между двумя скриптами. Через память, через временные файлы или еще не пойми как.
Помогите, пожалуйста. Если вы хотите предложить конкретный способ, то приложите понятный пример, по которому я мог бы использовать этот способ или правильно загуглить.
]]>