Блокировка вызовов (ожидание, ком-вызовы) в потоке STA

У меня есть служба Windows, которая создает более 10 потоков, которые:

  • выполните свою работу, а затем войдите в состояние WaitForMultipleObjects, пока они снова не возобновятся.
  • каждый поток создает метод вызова компонента TDCOMConnection на своем AppServer, а затем закрывает соединение

Служба работает нормально, однако я видел проблемы с утечкой памяти.

Мне просто любопытно, может ли эта проблема быть связана с перекачкой сообщений.

Я всегда думал, что перекачка сообщений в потоках STA должна применяться только тогда, когда я использую маршалинг com (в ситуации, когда у меня есть прокси между двумя потоками).

Но сегодня я где-то прочитал, что в случае блокировки звонков я должен заботиться о сообщениях. Это правда?

Однако мое приложение по-прежнему работает правильно, не блокирует себя...

Может быть, мне следует использовать: CoWaitForMultipleHandles вместо: WaitForMultipleObjects?

Есть мысли по этому вопросу?


person Paul    schedule 21.03.2011    source источник


Ответы (1)


Я не верю, что использование WaitForMultipleObjects вместо CoWaitForMultipleHandles приведет к утечке памяти. Какую функцию вы используете, действительно зависит от вас, но это не должно влиять на то, будет ли у вас утечка.

Чтобы решить эту проблему, я думаю, вам нужно получить подробную диагностику ваших утечек.

person David Heffernan    schedule 21.03.2011
comment
Да, мне придется покопаться, однако мне просто любопытно, должен ли я обрабатывать сообщения в своих потоках STA. - person Paul; 21.03.2011
comment
@ Пол Трудно сказать, не зная об этом больше. Видите ли вы проблемы так, как вы это делаете сейчас? - person David Heffernan; 21.03.2011
comment
на самом деле нет... кроме маленького.. утечка памяти. Мне кажется, что потоки, вызывающие методы com+, являются причиной моих проблем, потому что, если я удалю строки, которые вызывают эти методы, чтобы увидеть, правильно ли распределены/освобождены объекты Task, тогда все работает нормально, и память не растет. .. - person Paul; 21.03.2011