Здравствуйте, VladD2, Вы писали:
GZ>>Асинхронный вызов означает что вызывающий поток не ожидает результат вызова и тогда вызов асинхронен относительно вызывающего потока.
VD>Ага. Вот только ассинхронное опвевещение (колбэк) таки без другого потока не какти.
RPC и APC работают легко без доп. потока, просто нужен некий механизм ожидания в основном потоке, типа очереди сообщений, или "точка сбора" в одном месте, использующем ф-ию из семейства WaitForXXXObjects.
Т.е. в событийной модели асинхронность можно организовать без нескольких потоков. Другой вопрос — в гарантированности обработки событий, т.к. в данном случае налицо "кооперативная" многозадачность.
Re[14]: Асинхронная операция в рамках одного потока?
Здравствуйте, Tom, Вы писали:
Tom>Здравствуйте, GlebZ, Вы писали:
GZ>>Здравствуйте, Tom, Вы писали:
GZ>>>>С уважением, Gleb.
Tom>>>Можешь ответить на вопрос?
Tom>>>"Так вам не кажется, что слово "separately" это латентно "in some other thread"?" GZ>>Не вырывай из контекста. "separatly so that". Условие separatly построено строго. И никаких намеков на параллельное выполнение.
Tom>Хорошо, тогда скажи к чему болл применимо высказывание "...separatly so that...": Tom>1. in the same thread Tom>2. in the another thread
это более применимо к следующему:
3. at another time
например оверлаппед ввод-вывод работает через прерывания на уровне ядра и через APC на уровне пользователя. И никаких потоков. PostMessage — тоже весьма показательный пример.
Re[10]: Асинхронная операция в рамках одного потока?
. Если постараться, то можно найти и объяснение.
VD>И как найти это сообщение по словам из твоего сообщения?
А что, очень сложно? Вся информация в сообщении была ищем.
VD>ServicedComponent это всетаки довольно редкое исключение. Про него конечно на всякий случай нужно знать, но в данном случае он непричем.
рассказал бы тогда, что причем? Пусть и остальные знают... Вдруг, будет полезно для общего образования..
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
