Ну, может быть udpxy действует в таком порядке, а может и нет. Старый процесс умирает, и если даже ресурсы, занятые им, освобождаются когда-то потом (после старта нового процесса), то новый процесс как стартует в лагах, так и продолжает в них пребывать до бесконечности. Не взирая на то, что в какой-то момент ресурсы старого процесса, может быть, таки освобождаются...Quote:
Originally Posted by AndreyPopov
Что до времени рестарта прокси, я проверил уже, что время это мизерное. Я делаю GET реквест url "http://ip_роутера:1212/restart/", получаю респонс через ~10 мс, что инициирован рестарт. Потом GET реквест url "http://ip_роутера:1212/status/" и снова через ~10мс получаю ответ, что прокси уже работает (т.е. уже перезапущена и готова к работе). При переключении тв-каналов лишние 20 миллисекунд - это незаметный миг. Зато если заставить udpxy рестартить себя при каждом новом подключении, то выбор каждого нового канала будет подключать к свеже-рестартанутой прокси, это обеспечит отсутствие квадратов при любых манипуляциях с переключением каналов.
Вообще-то версию нехватки ресурсов (в частности памяти под процесс) - мы уже отринули. Т.к. у меня не только на роутере, а на стационарном компе с Ubuntu те же самые симптомы, хотя уж тут-то ресурсов точно в достатке. Боюсь, что недочёт есть именно в самом коде udpxy, связанный с закрытием старого клиентского процесса и запуске нового.Quote:
Originally Posted by AndreyPopov
