В классе CAsyncSocket есть переопределяемые функции типа OnAccept, OnReceive и т.д., в которых можно выполнять какие-то свои действия.
А кто их вызывает? Я имею в виду, какой поток вызывает сами эти функции?

Цитата(Dreamer_0x01 @ 20.12.2005, 14:54)

А кто их вызывает? Я имею в виду, какой поток вызывает сами эти функции?

Переопредели у себя в классе A (class A : public CAsyncSocket) OnAccept, OnReceive, поставь бряк, а потом уже на нем просмтори стек вызовов

А однозначного ответа на это нет что ли, зависит от ситуации?

Так это же (стек вызовов) самое простое решение.
Добавлено @ 16:53
Debug->Windows->Call Stack

Ясно, щас займемся.
Просто до дебага я еще не скомпилировал ;)

Dreamer_0x01
А зачем такие подробности, если не секрет?
Что надо вообщем-то?

Мне нужно работу с сокетами запихать в отдельный поток.

и в этом отдельном потоке нужно ожидать приема данных сокетом.
(Принцип простой - я запросил у внешнего устройства пакет данных и должен дождаться его получения).
Фот собственно с ожиданием и возникли проблемы - как быть?
В месте, где нужно ждать приема данных, так и просится создать цыкл какой-либо переменной, с заходом/выходом в критическую секцию, значение которой выставить по переопределяемой функции OnReceive класса сокета.
Вот и думаю - будет работать или нет? Ведь если сокет создает свой поток при инициализации, то все будет нормально. А если эти вункции вызываются тем потоком, в котором создан экземпляр сокета - то мой цикл попросту заснет...

Имхо ф-ция

Цитата(Dreamer_0x01 @ 21.12.2005, 13:43)

OnReceive

вызовится только тогда , когда прийдут данные на сокет, зачем здесь поток? Тем более что сокет асинхронный!!!

Функция вызывается не святым духом, а каким-то потоком. Каким? Моим, или каким-то другим, порожденным сокетом? Или оконным? Или главным потоком программы?

Имхо в стеке будет адресс твоего потока , но инициатором будет система

Так, посмотрел в дебаггере, кто вызывает эту функцию, написано, что WinMain. Это чей поток?

Твой

Romikgy прав.

Winsock (Ws2_32.dll) через ntdll.dll (NtDeviceIoControlFile, NtReadFile, NtWriteFile, NtCreateFile) обращается в kernel к девайсу \Device\AFD, которое отправляет TDI IRP-пакеты драйверам протокола, затем уже NDIS IRP-пакеты попадают в NDIS и через минипорт NDIS в драйвер сетевой карты, и потом в сеть. Если у тебя асинхронный сокет, то IRP пакет просто отмечается как отложенный (PENDING) и к тебе возвращается управление, а когда этот пакет "завершится" в kernel, он будет поставлен в очередь APC твоего потока и вот, когда твой поток получит управление (квант) он тебе и даст знать об OnReceive.

Dreamer_0x01
что-то запарился ты с сокетами.
Давай сюда проблему твою, сейчас решим

Да собственно что нужно.

Нужно, чтобы в программе были функции, работающие одинаково и с сокетами, и с ком-портом.

То есть где-то у меня есть струтура, в которой хранится инфа о том, с каким устройством какое соединение установлено, и эти вункции в зависимости от полей этой структуры рабтают либо с те, либо с другим.
И надо-то всего лишь адаптировать функции, использующие ReadFile(...) для работы с сокетами. То есть чтобы работа велась по тому же принципу:

1.В моем потоке команда типа Write отправляет информацию в сокет (это просто).
2.Мой прибор, работающий в режиме сервера, отвечает на этот запрос.(это сделано на отдельном контроллере).
3.В моем потоке команда типа Read ждет этого ответа прибора в течении какого-то времени. (У меня для этого используется таймаут ком-портов.)

Все это работает в своем, специально выделенном для этого потоке.

То есть мне самое сложное - грамотно дождаться ответа сокета в команде Read, так же, как это делается и для ком-порта. Пока что получается, но я бы сказал мягко говоря безграмотно - я наплодил кучу пользовательских сообщений, и вынес сокеты в отдельный поток, работает, но чувствую, что я с каждым днем перестаю понимать свой код =)