Ликвидировать демона

[Inhibitor]

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

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

Спасибо!

[qate]

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

[Inhibitor]

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

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

[sergek]

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

[ssoft]

Посмотрите в сторону Qt Service

[ssoft]

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

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

[sergek]

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

[qate]

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

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

[DarkHobbit]

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

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

[DarkHobbit]

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

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

Если что, я не настаиваю, что этот вопрос имеет однозначное решение. У QtCore до сих пор есть сильные "плюшки", например, ЧЕЛОВЕЧЕСКАЯ поддержка строк с юникодом и вообще перекодировками. А вот QtNetwork vs Boost и вообще зрелость сетевого стека в Qt --- тема очень-очень отдельного флейма (вот, например, страшная история с другого форума).

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

[Авварон]

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

[Inhibitor]

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

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

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

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

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

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

[qate]

А вот QtNetwork vs Boost и вообще зрелость сетевого стека в Qt --- тема очень-очень отдельного флейма (вот, например, страшная история с другого форума).

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

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

[qate]

Там внутре вообще select() испльзуется => проблему 10к на кутешных сокетах не решить.

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

[qate]

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

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