Здравствуйте, Слава, Вы писали:

С>Вообще в линуксе, в отличие от винды, не было изначально единого понятия "объект синхронизации", поэтому разные типы объектов IPC требуют разных методов для ожидания на них. И разные методы частично дублируют друг друга....

Ужс.

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, AlexGin, Вы писали:

S>Не совсем то, но в .Net есть асинхронная очередь AsyncProducerConsumerCollection

Афигеть! Я восемь лет назад сам примерно такую написал.

Здравствуйте, Философ, Вы писали:


S>>Не совсем то, но в .Net есть асинхронная очередь AsyncProducerConsumerCollection

Ф>Афигеть! Я восемь лет назад сам примерно такую написал.
Ну этому шаблону столько и лет! То есть как появились таски.

Здравствуйте, AlexGin, Вы писали:

AG>В процессе творческих поисков я наткнулся на тот факт, что работая под Windows (WinAPI & MFC) я нередко применял отправку сообщения потоку выполнения:

AG>Мог ли бы кто-нибудь подсказать мне — что же в Unix (Linux) системах соответствует всему вышеперечисленному?


Кто-то может сказать что общего подхода к реализации "цикла обработки сообщений" в Linux нет.
Но на самом деле он есть.

На Linux две популярные GUI библиотеки: Qt и Gtk.
И если взглянуть на исходный код Qt, то можно обнаружить qeventdispatcher_glib.cpp .
То есть Qt может использовать тот же код обработки очереди сообщений что и gtk (glib это базовая
библиотека в составе gtk, на основе которой все и строиться).

В Qt это нужно чтобы например использовать те же файловые диалоги, что и остальные программы
в Destkop Envrionment,
или например использовать популярную библиотеку gstreamer, которая уже упоминалась.

И большинство разработчиков дистрибутивов Linux собирают Qt с поддержкой glib.

То есть "почти" наверняка GUI приложение будет вызывать в цикле "g_main_context_iteration".

А что же делает "g_main_context_iteration"? А он реализован на основе poll/ppoll.
То есть ждет события для множества файловых дексрипторов (на Linux это сокеты,
пайпы и так далее).

А что будет если взглянуть внутрь большинства серверных приложений для Linux,
причем неважно на чем они будут написаны, на C,Rust,TypeScript или Go.

Там тоже будет в цикле вызывать poll/ppoll/epoll.

Так что на самом деле общий подход к циклу обработки сообщений в Linux есть — вызов epoll,
определение для какого файлового дескриптора что-то произошло,
обработки события с этим файловым дескриптором и вызова epoll заново.

Здравствуйте, Философ, Вы писали:

С>>...Большое преимущество этих сокетов перед named pipes — это нормальный путь к сокету, вместо \\.\pipe\PipeName

Ф>А что не так с именами пайпов в винде? Для меня это привычно и нормально. Какие пути к сокету в юниксе — сорри, гуглить сейчас лень.

Эти имена в юниксе постоянные, то есть они остаются и после завершения работы процесса. Вы можете взять обычные, привычные инструменты и скажем установить права доступа на этот пайп, если автор оригинальной программы идиот сделал не так, как надо вам. А теперь удачи сделать то же самое в винде, отследить появление чужого пайпа, изменить его права доступа. Для чего это например надо — есть некая программа, которая работает только под админом, а надо чтобы работала под обычным пользователем.

Здравствуйте, Zhendos, Вы писали:

Z>Кто-то может сказать что общего подхода к реализации "цикла обработки сообщений" в Linux нет.
Z>Но на самом деле он есть.
Вот я тоже "подозревал" что он есть

Z>На Linux две популярные GUI библиотеки: Qt и Gtk.
Z>И если взглянуть на исходный код Qt, то можно обнаружить qeventdispatcher_glib.cpp .
Z>То есть Qt может использовать тот же код обработки очереди сообщений что и gtk (glib это базовая
Z>библиотека в составе gtk, на основе которой все и строиться).
Интересно, интересно...

Z>В Qt это нужно чтобы например использовать те же файловые диалоги, что и остальные программы
Z>в Destkop Envrionment,
Z>или например использовать популярную библиотеку gstreamer, которая уже упоминалась.
+100500

Z>И большинство разработчиков дистрибутивов Linux собирают Qt с поддержкой glib.
Когда выбираем при установке Qt пакет поддержки gcc, поддержка glib, вероятно, также ставиться?

Z>То есть "почти" наверняка GUI приложение будет вызывать в цикле "g_main_context_iteration".
Предположим, что всё это вполне логично.

Z>А что же делает "g_main_context_iteration"? А он реализован на основе poll/ppoll.
Z>То есть ждет события для множества файловых дексрипторов (на Linux это сокеты,
Z>пайпы и так далее).
Поищу это, скорее всего всё именно так.

Z>А что будет если взглянуть внутрь большинства серверных приложений для Linux,
Z>причем неважно на чем они будут написаны, на C,Rust,TypeScript или Go.
Z>Там тоже будет в цикле вызывать poll/ppoll/epoll.
То есть — те же "демоны" и приложения CLI также крутят цикл сообщений?

Z>Так что на самом деле общий подход к циклу обработки сообщений в Linux есть — вызов epoll,
Z>определение для какого файлового дескриптора что-то произошло,
Z>обработки события с этим файловым дескриптором и вызова epoll заново.
+100500

Вот такого толкового ответа я и ждал!
Огромное Спасибо, уважаемый Zhendos, за столь развёрнутый ответ

Здравствуйте, AlexGin, Вы писали:

Z>>И большинство разработчиков дистрибутивов Linux собирают Qt с поддержкой glib.
AG>Когда выбираем при установке Qt пакет поддержки gcc, поддержка glib, вероятно, также ставиться?

Здесь не нужно путать. Есть glibc , это реализация "C runtime",
а есть glib, без "C" на конце. Это ядро/основа gtk. Там заложена основа ООП для С,
которая используется в gtk, там реализован цикл обработки сообщений,
там есть работа с юникодом, обертка для кроссплатформенной работы с потоками и так далее и тому подобное,
в общем все что нужно для работы с GUI, но что к GUI не относиться напрямую.

glib никакого отношения к gcc не имеет, в отличие от glibc.

Z>>Там тоже будет в цикле вызывать poll/ppoll/epoll.
AG>То есть — те же "демоны" и приложения CLI также крутят цикл сообщений?

"Демоны" конечно, прием данных по TCP/IP это же ожидание соединения,
чтение данных которые прислал клиент и отправка ему ответных данных.

С помощью epoll это просто три события: есть входящее соединение (1),
есть доступные данные для чтения из буфера ОС (2), и ОС готова принять данные для отправки (3).

В CLI в простейшем случае нет никаких "event loop" конечно.

Но если например нужно читать откуда-то с "timeout",
или читать из двух источников данных одновременно, скажем stdin,
но плюс нужно реагировать на сигналы, то тут опять без poll/select не обойтись.

Здравствуйте, AlexGin, Вы писали:

AG>В процессе творческих поисков я наткнулся на тот факт, что работая под Windows (WinAPI & MFC) я нередко применял отправку сообщения потоку выполнения:

Не совсем понятно зачем вы пытаетесь притащить свой виндовый опыт в линуха.
Какую проблемы вы пытаетесь решить? Вполне возможно, что тут оно по другому просто решается.