Russian Qt Forum

Товарищи профессионалы, нужен совет.

Есть исходный код написанный под Linux, в котором задействован демон. Qt не используется. Задача стоит переписать данный код средствами Qt, дабы помимо пользователей Linux были так же осчастливлены многочисленные пользователи Венды. Подскажите, пожалуйста, в каком направлении копать?

Спасибо!

сути проблемы не уловил и что значит "задействован демон" ?

В main.cpp первым делом создается демон через стандартную процедуру: fork(), umask(), setsid() и так далее...

Посмотрите в сторону QtService.

Посмотрите в сторону Qt Service (https://github.com/qtproject/qt-solutions/tree/master/qtservice)

Как синхронно получилось))

штампы, что поделаешь))

так убрать их не  ?

Интересная вещь, спасибо.
А он вообще поддерживаемый? Я смотрю, последний коммит был 4 года назад. Да и статус всего проекта qt-solutions вызывает интерес. Я так понял, это набор библиотек от разработчиков Qt, но при этом в саму Qt не входящих?..

Я бы, кстати, задался вопросом: а нужна ли в таком серверном проекте вообще Qt, и не решаема ли задача средствами "чистого" современного C++ (возможно, с привлечением Boost, в частности, Boost.Asio, но и STL сейчас очень сильно подрос)?

Если что, я не настаиваю, что этот вопрос имеет однозначное решение. У QtCore до сих пор есть сильные "плюшки", например, ЧЕЛОВЕЧЕСКАЯ поддержка строк с юникодом и вообще перекодировками. А вот QtNetwork vs Boost и вообще зрелость сетевого стека в Qt --- тема очень-очень отдельного флейма (вот, например, страшная история с другого форума (http://www.forum.crossplatform.ru/index.php?showtopic=10976)).

Решать Вам, конечно. Мне, кстати, интересно, что же Вы в итоге решите.

QtNetwork оно об удобстве а не о производительности. Там внутре вообще select() испльзуется => проблему 10к на кутешных сокетах не решить.
АСИО я не трогал лет 6 но и тогда оно тоже недалеко ушло от кутешных сокетов - там внутри все было "поперчено" мьютексами которые безбожно тормозили.
Возможно за 6 лет что-то и поменялось в лучшую сторону но я бы смотрел на голый epoll или тонкие обертки над ним и аналогами

Ну как бэ да  ::) Точнее не убрать, а написать в Qt реализацию годную для обоих платформ.


Посмотрел. Товарищ DarkHobbit озвучил мои опасения. Это про коммит четырехлетней давности. Так что пока в раздумиях...


Увы, это не чисто серверное приложение, GUI там присутствует в достаточном количестве. А ваять вменяемый GUI без Qt мы уже не умеем ;D (Давеча листал код с MFC  :o   God bless the Qt!  :D)

а можно ли подробнее про недостатки QtNetwork vs Boost  ?

на том форуме нет кода, хз что там ТС еще делал, и версия qt старая

была проблема 1024 сокетов, ее решили после 5.6

если для linux это systemd или иное, то уже не две реализации  )

могу предложить такое решение - писать программу без демонизации "как обычно", затем :
1. linux = https://askubuntu.com/questions/610017/running-a-command-in-screen-daemon-mode
2. windows = https://superuser.com/questions/643120/windows-powershell-screen-equivalent

Глянул в код, действительно, они иногда используют poll(), а иногда qt_poll (https://code.woboq.org/qt5/qtbase/src/corelib/kernel/qpoll.cpp.html#_Z7qt_pollP6pollfdmPK8timespec), который использует select() ;D
Видимо, некоторым платформам не повезло.
Но всё равно, poll() тоже не является серебряной пулей и дескрипторы надо перебирать - алгоритмическая сложность O(N).
Я уж молчу что сокеты нельзя на тредпул раскидать.

А какие есть иные варианты?

А вот asio использует epoll, легко раскидывает обработку на пул потов и мьютексы у него где надо, конечно если хотим на нескольких ядрах все крутить. А если не хотим, то флажочек указываем и он мьютексы все отключает. :)

(густо краснеет) Ну на самом деле, у меня бы это были не основные опасения. Тут нужно просто взять и проверить, насколько оно хорошо работает с актуальными (для вас) версиями Qt, на линуксе и на винде. Практика - критерий истины.

Вот с сетевой работой возможны более серьёзные (и не сразу выявляемые) грабли. Оно у вас планируется к работе 24/7 или только в течение рабочего дня?

Хм, тогда не очень понял, при чём тут демон. В комплексе несколько программ, одна работает как демон, остальные с GUI?

Но ведь основная прелесть еполла что к дескриптору можно привязывать контекст и тем самым обеспечивать разделение по данным, то есть никакие мьютексы там нафик не нужны.

И asio использует эту возможность epoll.
Но, если мы говорим про пул потоков, то даже если мы сразу получили дескриптор сокета, событие и контекст, нам нужно впихнуть обработчик этого события в пул потоков, а это мьютекс + условная переменная.
  

Погодите, там что, еполл отдельно а пул отдельно?

Отдельно от чего? :)
В asio есть io_context, это некотрый аналог QEventLoop, который можно запустить в 1 потоке, а можно и в 101.
Все сокеты/таймеры привязываются к этому контексту.
Вот как тут понять, отдельно или нет? :)

Но я говорил про решение без привязки в чему либо. Если у нас есть пул потоков, то у нас мьютекс. Да epoll нас избавляет от еще одного мьютекса на коллекцию сокет -> контекст.

Qate, спасибо за идею, попробую, наверное, Ваше предложение реализовать.


В течение рабочего дня. А иногда и того меньше.


Основное приложение крутится как демон, настройка и управление этим приложением реализовано через GUI.

Ну тогда можно применение Qt ограничить именно управляющей программой, а основное приложение написать на чистом C++, возможно, с бустом. Но это не догма, это один из вариантов. Главное понимать, что вы хотите получить от Qt в "серверном" варианте.

А вот идея писать программу без демонизации, а потом пускать её под screen мне совсем не нравится. Это же костыль для ситуации, когда других вариантов нет. Я, например, OpenSimulator на VDS так пускал, и это, считаю, одна из причин, затрудняющих его распространение. Тем более, для винды и линукса костыли разные потребуются. :( Я бы всё-таки, если делать демона на Qt, потыкал бы сначала QtService.