LINUX.ORG.RU

Реалтайм потоки и права вэбсервера.

 


0

2

Господа. Диспозиция такова. ОС Убунту. Есть вэбсервер, который рулит циклом жизни некоего процесса-программы. В последнем обновлении в этой программе часть потоков была переведена в режим работы с реалтайм приоритетом. Для того, чтобы это работало, программу стали запускать от лица пользователя root. Но как только это произошло, вэб сервер потерял возможность завершать программу через killall и создавать с надлежащими правами, так вэб сервер исполняется не от лица root.

Как эту проблему покрасивше разрешить?


реалтайм

У вас rt-ядро? Если нет, то имеет ли смысл делать реалтайм-потоки? И вообще, с какой целью вы это сделали?

// Интересуюсь с целью изучения интересных случаев

XMs ★★★★★
()
Последнее исправление: XMs (всего исправлений: 1)
Ответ на: комментарий от XMs

Если нет, то имеет ли смысл делать реалтайм-потоки?

Судя по описанию там просто приоритет подняли.

micronekodesu ★★★
()
Ответ на: комментарий от XMs

Если я все правильно понял, необходимо было, чтобы без существенных изменений кода установить приоритетный порядок входа в защищенную мьютексом секцию для этих потоков. По сути необходимости именно в реалтаймовом приоритете не было.

Ядро не rt, но lowlatency. Это сделано для уменьшения временных задержек и увеличения стабильности в обработке сообщений из com порта.

Строго говоря, знаний об администрировании таких систем нехватает, а потому все делается методом тыка.

Mirmik
() автор топика
Ответ на: комментарий от Mirmik

без существенных изменений кода установить приоритетный порядок входа в защищенную мьютексом секцию для этих потоков

Очень ненадёжное решение, как по мне. Не лучше ли сделать семафор и рулить через него?


Это сделано для уменьшения временных задержек и увеличения стабильности в обработке сообщений из com порта

Так ведь скорость передачи данных в COM-порте много меньше скорости их обработки. Тут, КМК, даже обычное ядро справится без проблем

XMs ★★★★★
()
Ответ на: комментарий от XMs

Наверное лучше. Но как всегда, нет времени на эксперименты.

По компорту.. Опыт показал, что стабильность выросла. Впрочем, это было давно. Я не помню конкретных цифр.

Mirmik
() автор топика
Ответ на: комментарий от Mirmik

В дополнение к предложению анона...

Я бы ещё с портом работал через epoll(), а не через select(). В случае с select() жрёт ресурсы как не в себя. Сырец надо приложить? Там всё просто — открываем порт как обычно, а дальше epoll.

Moisha_Liberman ★★
()
Ответ на: комментарий от Mirmik

Ядро не rt, но lowlatency. Это сделано для уменьшения временных задержек и увеличения стабильности в обработке сообщений из com порта.

э com порт это типа RS232? и скорость у вас там гигабиты туда и обратно, раз вам не хватает процесора LOL

anonymous2 ★★★★★
()
Ответ на: комментарий от redixin

Да.

На распберри я бы вообще-то задумался. На распберри от батарейки, задумался бы вдвойне что дешевле — проверять наличие чего-либо в буфере порта селектом или ждать появления данных в пассивном режиме. Если бы я замерил потребление при использовании селект и epoll(), то мне бы не до смеха стало.

Впрочем, да наверное, на фиг нам не нужны более совершенные системные интерфейсы, огггада...

Moisha_Liberman ★★
()
Ответ на: комментарий от anonymous2

Вообще-то...

Не оговорено что за процессор. И что подразумевается под обработкой данных. Если прочёл из СОМ и вывел на экран, это одно. А если прочёл из СОМ, распарсил и попробовал отправить на удалённый MQTT-брокер, то другое. Просто потому, что публикация данных в брокере идёт по сети и тут возможны задержки. И, если те же 115200 читать локально и публиковать куда-то, то возможна ситуация когда код публикатора нужно будет вынести в отдельный поток, а чтение из порта в другой.

Но тут все вопросы к ТС, я не знаю какую задачу он пытается решить.

Moisha_Liberman ★★
()
Ответ на: Gut... от Moisha_Liberman

ни чего объяснять

ни чего

Астанавись!

redixin ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.