История изменений
Исправление filosofia, (текущая версия) :
Я не имел в виду чего-то конкретного. Боюсь, ты додумал что-то, и ответил на это.
В зависимости от реализации event loop, отправка приоритетного сообщения в него может быть очень разной. Для большинства IO event loop можно сделать нотификацию через файловый дескриптор или аналог. В таком случае «приоритетность» определяется просто тем, что ты в первую очередь обрабатываешь сообщения с этого дескриптора, потом смотришь на остальные.
Да, в терминальном случае это может быть и priority queue. В плюсах она уже есть, ничего выдумывать не надо. Как минимум в двух вариантах: std::priority_queue и std::[multi]set. Но повторюсь, это крайний случай.
Когда вы предлагаете играться со всякими булевыми флагами, это часто заканчивается грязными хаками, чтобы разбудить event loop. И тут вы либо фактически копируете код отправки сообщения в него; либо код ожидания в event loop становится бесконечным циклом проверки флага, конечно же с таймаутом. Первый вариант в итоге и есть пресловутая отправка сообщения, с изюминкой. Второй вариант — это latency и говнокод.
Да, убивать поток или even loop во время выполнения задачи можно, для этого в ней должны быть контрольные точки. Если хочется прямо зарезать поток посреди выполнения и ни о чем не думать, обработчик сигнала вообще не нужен.
Исправление filosofia, :
Я не имел в виду чего-то конкретного. Боюсь, ты додумал что-то, и ответил на это.
В зависимости от реализации event loop, отправка приоритетного сообщения в него может быть очень разной. Для большинства IO event loop можно сделать нотификацию через файловый дескриптор или аналог. В таком случае «приоритетность» определяется просто тем, что ты в первую очередь обрабатываешь сообщения с этого дескриптора, потом смотришь на остальные.
Да, в терминальном случае это может быть и priority queue. В плюсах она уже есть, ничего выдумывать не надо. Как минимум в двух вариантах: std::priority_queue и std::[multi]set. Но повторюсь, это крайний случай.
Когда вы предлагаете играться со всякими булевыми флагами, это часто заканчивается грязными хаками, чтобы разбудить event loop. И тут вы либо фактически копируете код отправки сообщения в него; либо код ожидания в event loop становится бесконечным циклом проверки флага, конечно же с таймаутом. Первый вариант в итоге и есть пресловутая отправка сообщения, с изюминкой Второй вариант — это latency и говнокод.
Да, убивать поток или even loop во время выполнения задачи можно, для этого в ней должны быть контрольные точки. Если хочется прямо зарезать поток посреди выполнения и ни о чем не думать, обработчик сигнала вообще не нужен.
Исходная версия filosofia, :
Я не имел в виду чего-то конкретного. Боюсь, ты додумал что-то, и ответил на это.
В зависимости от реализации event loop, отправка приоритетного сообщения в него может быть очень разной. Для большинства IO event loop можно сделать нотификацию через файловый дескриптор или аналог. В таком случае «приоритетность» определяется просто тем, что ты в первую очередь обрабатываешь сообщения с этого дескриптора, потом смотришь на остальные.
Да, в терминальном случае это может быть и priority queue. В плюсах она уже есть, ничего выдумывать не надо. Как минимум в двух вариантах: std::priority_queue и std::multiset. Но повторюсь, это крайний случай.
Когда вы предлагаете играться со всякими булевыми флагами, это часто заканчивается грязными хаками, чтобы разбудить event loop. И тут вы либо фактически копируете код отправки сообщения в него; либо код ожидания в event loop становится бесконечным циклом проверки флага, конечно же с таймаутом. Первый вариант в итоге и есть пресловутая отправка сообщения, с изюминкой Второй вариант — это latency и говнокод.
Да, убивать поток или even loop во время выполнения задачи можно, для этого в ней должны быть контрольные точки. Если хочется прямо зарезать поток посреди выполнения и ни о чем не думать, обработчик сигнала вообще не нужен.