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

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

A>>>может поможет WaitForMultipleObjectsEx + QueueUserAPC ?
PD>>>ИМХО проще MsgWaitForMultipleObjects. В нужный момент послать туда что-нибудь PostMessage...

NB>>есть куча типов объектов синхронизации, под которые заточены WaitForMultipleObjects и WaitForMultipleObjectsEx. зачем еще кучу других наворотов добавлять? результат-то один. не проще ли SetEvent сделать?

A>Конечно проще, только это не будет решением заданного вопроса.


Проблема не стоит таких решений. Легче написать свой WaitFor***, может ещё когда пригодится.

Миша.

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

A>>может поможет WaitForMultipleObjectsEx + QueueUserAPC ?
PD>>ИМХО проще MsgWaitForMultipleObjects. В нужный момент послать туда что-нибудь PostMessage...

NB>ага... одно другого проще...
NB>один хочет APC навернуть, другой мессаги слать...
NB>НАХРЕНА???
NB>есть куча типов объектов синхронизации, под которые заточены WaitForMultipleObjects и WaitForMultipleObjectsEx. зачем еще кучу других наворотов добавлять? результат-то один. не проще ли SetEvent сделать?
NB>З.Ы. а WaitForMultipleObjectsEx с собщениями работает для совместимости с псевдомногозадачной Вынь 3.х

Если под Вынь 3.х ты имеешь в виду 16-bit Windows 3.x, то там не было никаких Wait* и объектов ядра в нынешнем понимании тоже.

Что же касается SetEvent... Дело в том, что это надо сделать атомарно. Иными словами, два Wait — не решение. А автору письма нужно ждать

(A and B and C... and X) or Y

Такого механизма ожидания в ядре нет, а эмулировать в третьем кольце нельзя по известным причинам — синхронизация должна обязательно проводиться в ядре.

Поэтому остаюсь при своем мнении.

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

TC>>Прерывание ожидания через АРС — наиболее правильный способ.

NB>он правильный, только в том случае, когда АРС нужен. а лепить функцию, которая ничего не делает, а только косвенно ожидание прерывает — изврат
Изврат, это то что вы предложили здесь

Автор: NightBlade
Дата: 07.06.06

, в пунктах 1 и 2, а использование базовых механизмов ОС (коими являются APC и Windows Messages) нормальная весчь.

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

MT>Добрый день.

MT>Не подскажете, как отменить WaitForMultipleObjects?

MT>Имеем кучу объектов, и WiatForMultipleObjects вызвана с параметром bWaitAll = TRUE. Но в какой-то момент надо завершить ожидание по другому событию.

MT>Т.е. WaitForMultipleObjects реализует схему (O1 | O2 | ... | On) при bWaitAll = FALSE и (O1 & O2 & ... & On) при bWaitAll = TRUE. А мне хочется что-то типа (O1 & O2 & ... & On) | Om. Кроме как играться со временем ожидания или переводить всё на bWaitAll = TRUE ничего на ум не приходит.


MT>Спасибо.

MT>Миша.

Такой тип функции WaitFor... какой тебе нужен описан у Рихтера, только он предлагает нижеописанное решение для ожидания более чем 63 событий.

Идея такая:

Создаем поток в которм WaitForMultiplaObjects ждет O1,O2, ... ,On. Далее в другой функции ждем 2 события: Oexit и Хендлер на поток. Осталось только решить что делать с потоком, если сработает событие Oexit. Дамаю что впринципе его можно без риска уничтожить TerminateThread.

PD>два Wait — не решение

да, в общем случае. но, если известно, что объект меняет состояние только один раз (поток например), то можно и два Wait поставить.

З.Ы. я тут неправильно формулировал, когда флаги обсуждал, конечно Wait пропустит установленный объект, но вот если объект будет сингналить туда-сюда, то атомарность необходима

проанализировав все вышеизложенное хочу сказать следующеее:

во-первых, если где погорячился — прошу простить (относится ко всем, писавшим в тему). никто от ошибок не застрахован. а истина — она в спорах рождается

как я понял, каждый объект сигналит один раз (ждем хандлеры потоков, отработал — отсигналил)
поэтому предлагаю следующее:
1. складываем все хандлеры в массив таким образом, что превым всегда стоит "с вещами на выход!". устанавливает счетчик объектов в соответствии с их количеством
2. делаем Wait с выходом по любому объекту
3. если выход по индексу 0 или счетчик равен 2 (т.е. в массиве остался только "выходной" и последний отработанный объекты) — завершаем цикл
4. замещаем отработанный хандлер в массиве на тот, на который счетчик указывает
5. делаем декремент счетчика
6. переходим к пункту 2