Очистка и прочее управление очередями

[Bepec]

Ну я не сомневаюсь, что можно написать потоки с имитацией поддержки очереди сигналов
Получить все сигналы возможность есть. Получить все связи возможность есть.
Остаются простые вопросы как - при дисконнекте очередь теряется или остаётся.

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

PS придумали в общем какую то неживую архитектуру, где пользователь творит херню

[Гурман]

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

[Igors]

События (Events) я в своем приложении вообще не создаю и не использую, и не собираюсь - только обрабатываю всякие интерфейсные, которые сам Qt посылает, по необходимости.

Сигналы с QueuedConnection сами выливаются в Events.

Насчет "очистки", "объединения" очередей - это спорно/проблематично. Напр взял и очистил - а там сидел deleteLater. А потом еще найдется "исключение из правил" которое опять придется отслеживать. Как-то мутно получается.

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

Если используете wakeOne/All проверьте что мутекс захвачен, это коварная ошибка которая может долгое время не проявляться а тихо гадить.

По поводу Flush - да, такая нужда может возникнуть, но почему бы не решить это более простыми средствами? Напр установить нитке флаг "игнорировать события" а самому послать queued сигнал который этот флаг сбросит. При этом не нужно менять код обработчика, можно все сделать во внешнем фильтре.

[Гурман]

Проблем с wakeOne/All у меня нет (вообще эти моменты на семафорах сделаны), остановка или просто задержка нити может происходить по внешним причинам. Например, передатчик быстро генерирует управляющие команды, а приёмник посылает их на внешний прибор и считывает с него ответ. А между посылкой команды и получением ответа надо выдерживать паузу 200 мсек. В результате приемник команд обрабатывает команды только каждые 0.2 сек. А передатчик команд может молотить их по чем зря. А потом прибор вдруг не ответил, выдал ошибку - приёмник команды должен выдать сообщение и стать в ожидании действия оператора. И после ответа оператора все команды, которые были посланы передатчиком, уже не нужны, их надо выкинуть - а они сейчас сидят в очереди. Это одна из возможных ситуаций, для которых надо специально предусматривать дополнительные синхронизации, сигналы управления, какие-то ухищрения и т.д. Хотя, если бы была просто приостановка передатчика по заполнению очереди некоей выделенной длины - это можно было бы использовать одинаково со всеми внешними приборами, которые имеют задержку ответа, и которые не имеют. Ну а без очистки очереди просто @$#%&@Q#... Пока пришлось в одном случае вые...ться и сделать специальный цикл выборки очереди в приемнике.

Насчет deleteLater - ИМХО это уже выдумка. Если такой объект послать в очередь обмена между нитями, то вообще не вполне понятно, когда он будет удален даже без очистки очереди. Может грохнуться в момент получения слотом в параллельной нити. Я бы такие объекты в очередь не пихал.

[Igors]

Насчет deleteLater - ИМХО это уже выдумка. Если такой объект послать в очередь обмена между нитями, то вообще не вполне понятно, когда он будет удален даже без очистки очереди. Может грохнуться в момент получения слотом в параллельной нити. Я бы такие объекты в очередь не пихал.

Вы бы не пихали. А автор одного из Ваших плагинов - запихнул. Это я просто для примера, к тому что возможность "очистить очередь" вряд ли принесет много счастья, скорее наоборот, добавит головняка. Ведь придется разбираться что можно мочить а что нельзя - это как минимум несладко.

Ну а без очистки очереди просто @$#%&@Q#... Пока пришлось в одном случае вые...ться и сделать специальный цикл выборки очереди в приемнике.

Не вижу повода для эмоций/негодования. По-моему такое решение грамотнее и надежнее "очистки событий". Да, приемник оповещен и знает что до какого-то события надо игнорировать какие-то действия, что в этом плохого?

[Гурман]

Насчет deleteLater - ИМХО это уже выдумка. Если такой объект послать в очередь обмена между нитями, то вообще не вполне понятно, когда он будет удален даже без очистки очереди. Может грохнуться в момент получения слотом в параллельной нити. Я бы такие объекты в очередь не пихал.

Вы бы не пихали. А автор одного из Ваших плагинов - запихнул. Это я просто для примера, к тому что возможность "очистить очередь" вряд ли принесет много счастья, скорее наоборот, добавит головняка. Ведь придется разбираться что можно мочить а что нельзя - это как минимум несладко.

Ну а без очистки очереди просто @$#%&@Q#... Пока пришлось в одном случае вые...ться и сделать специальный цикл выборки очереди в приемнике.

Не вижу повода для эмоций/негодования. По-моему такое решение грамотнее и надежнее "очистки событий". Да, приемник оповещен и знает что до какого-то события надо игнорировать какие-то действия, что в этом плохого?

Первый случай решается легко строкой в документации - "нельзя посылать в очередь объекты с deleteLater, кто послал, тот сам дурак". А вот второй случай означает, что авторам плагинов надо будет знать, в каких случаях писать собственный код для очистки очереди, в каких нет. Либо мне надо в родительском классе плагинов как-то предусматривать возможность выборки мусора из очереди (она может не в каждом случае потребоваться), чтобы самим авторам этого не пришлось делать, но тогда надо еще и в документации описать использование всего этого. То есть, отсутствие возможности просто очистить очередь одним вызовом, а вместо этого необходимость множества не совсем тривиальных действий, и порождает негодование. Тем более обоснованное, что внутри Qt это наверняка есть.

[Igors]

Первый случай решается легко строкой в документации - "нельзя посылать в очередь объекты с deleteLater, кто послал, тот сам дурак". А вот второй случай означает, что авторам плагинов надо будет знать, в каких случаях писать собственный код для очистки очереди, в каких нет. Либо мне надо в родительском классе плагинов как-то предусматривать возможность выборки мусора из очереди (она может не в каждом случае потребоваться), чтобы самим авторам этого не пришлось делать, но тогда надо еще и в документации описать использование всего этого. То есть, отсутствие возможности просто очистить очередь одним вызовом, а вместо этого необходимость множества не совсем тривиальных действий, и порождает негодование. Тем более обоснованное, что внутри Qt это наверняка есть.

А не лучше ли не связываться ни с какой "очисткой" а решить это запросом статуса на приемнике и/или передатчике? Псевдокод как это решается в плагинах моей системы

Код

C++ (Qt)
SInt32 PluginCommand( UInt32 theCommand, .. )
{
 switch (theCommand) {
  case commandCreateGeometry:
    for (size_t i = 0; i < N; ++i) {
      if (GetObjectStatus(dstObject) != noErr)
        return code_Aborted;
      AddVertex(dstObject, i, ...);
   }
   return noErr;
...
}

Т.е. перед посылкой запросить статус, а не так, "на деревню дедушке". Вообще всегда есть коды возврата и текущее состояние плагина - через них и надо действовать, т.е. цивильно, вместо цыганщины с "очисткой очереди".

[Гурман]

Не поможет. Потому как когда в предыдущем примере приемник встанет по ошибке прибора, будет поздно пить боржоми - в очереди уже будет дофига ненужного. А если жестко синхронизировать передатчик и приёмник (напоминаю, что они в разных нитях), то они уже не независмы. Но по задаче подразумевается, что передатчик ничего не знает о приемнике, а приемник о передатчике. Приемники могут быть разные и передатчики разные. Даже обмен идет в QVariant обертках. И даже соединения могут меняться пользователем динамически.