У меня есть класс в приложении-службе Windows, который вызывает MessageQueue.BeginReceive() для получения сообщений из очереди по мере их поступления.Ранее это делалось в контексте основного потока службы, но я переместил его в отдельный поток (по одному на очередь).
Вызов BeginReceive по своей сути неблокирует;в этом весь смысл метода.Я считаю, что внутренне среда выполнения использует порт завершения ввода / вывода (IOCP) для выполнения магии асинхронности, и, как я полагаю, это также отдельный управляемый поток (IOCP хороши, но они являются блокирующими).
Когда я переписал класс чтения очереди для запуска в отдельном потоке, я сделал это, ожидая, что асинхронный прием больше не будет полезен, так как он не сможет блокироваться, что приведет к немедленному завершению процесса потока,Я предполагал, что вместо этого мне придется переключиться на решение для опроса.
Поэтому я был удивлен, когда впервые запустил ридер в отдельном потоке, и каким-то образом вызов BeginReceive / EndReceive вызывает (я думаю)поток для блокировки, пока очередь не закрыта.
Итак, я ожидал, что процесс потока вернется, как только будет вызван BeginReceive, поскольку он не блокируется.Но это не работает таким образом.Используемая им версия читающего класса просто сидит, счастливо получая сообщения в отдельном потоке, пока я не дам ему сигнал на выход и очередь закрыта.
Теперь не поймите меня неправильно, это хорошо.Но я пытаюсь понять, почему управляемый поток каким-то образом блокируется на выход из операции, которая происходит в отдельном потоке (BeginReceive) и о которой он абсолютно ничего не знает.Мне нужно знать, как это работает, чтобы решить, является ли это жизнеспособным, стабильным подходом.Управляемый поток каким-то образом «знает», что существует ожидающая асинхронная операция или что-то подобное?