midas and callback

← →
Dedushka_Mazai © (2004-03-11 14:00) [0]

как можно организовать callback для трёхзвенки (tsocketconnection)?

← →
Nikolay M. © (2004-03-11 14:02) [1]

http://rsdn.ru/article/db/callback.xml
:) В Потрепаться в одной из веток обсуждается :)

← →
Digitman © (2004-03-11 14:02) [2]

не знаю как в Д7, но в Д5 без основательной переделки BSS не обойтись

← →
Romkin © (2004-03-11 14:15) [3]

Щаз! Там как раз на D5 сделано...

← →
Nikolay M. © (2004-03-11 14:23) [4]

> Romkin © (11.03.04 14:15) [3]

Кулхацкер ты :)

← →
Digitman © (2004-03-11 14:30) [5]

> Romkin © (11.03.04 14:15) [3]

я видел этот код

согласись, это - эрзац-колбэк, а не настоящий колбэк ...

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

← →
Polevi © (2004-03-11 14:34) [6]

у меня вообще есть подозрения что при определенных условиях этот код не будет работать

← →
Digitman © (2004-03-11 14:38) [7]

> Polevi © (11.03.04 14:34) [6]

и они вполне оправданы

← →
Romkin © (2004-03-11 14:49) [8]

А фиг его знает :((
Я так и не дошел до реальной реализации.
>сериализация в контексте одного и того же код.потока накладывает серьезные ограничения.. потому и упомянул о необходимости переделки BSS

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

← →
Nikolay M. © (2004-03-11 14:51) [9]

> Polevi © (11.03.04 14:34) [6]
> у меня вообще есть подозрения что при определенных условиях
> этот код не будет работать

Подтверждаю (чисто из практики). Просто нагло содрал код один в один, встроил в свою программу как фичу менеджерам для обмена сообщениями. Иногда сообщение уходило в никуда без каких бы то ни было ошибок.

← →
Romkin © (2004-03-11 15:00) [10]

Дык надо было оттрассировать, и исправление - в комментарии :)

← →
Digitman © (2004-03-11 15:09) [11]

> Romkin © (11.03.04 14:49) [8]

> Это о том, что на клиенте обратный вызов в основной поток
> идет?

основной или не основной - не важно ... в вызывающий ..

т.е. вызывающий поток клиента сделал запрос (callsig) и ждет результата (resultsig) .. вместо этого он в ответ может получить кучу callsig-пакетов и вынужден их обрабатывать и возвращать resultsig

к тому же rdm , работающий под контролем BSS, не имеет возможности инициировать колбэк асинхронно, в произвольный момент времени (только в момент времени, когда как реакция на запрос клиента выполняется некий из методов объекта в этом rdm)

← →
Romkin © (2004-03-11 15:19) [12]

>т.е. вызывающий поток клиента сделал запрос (callsig) и ждет результата (resultsig) .. вместо этого он в ответ может получить кучу callsig-пакетов и вынужден их обрабатывать и возвращать resultsig

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

>к тому же rdm , работающий под контролем BSS, не имеет возможности инициировать колбэк асинхронно, в произвольный момент времени (только в момент времени, когда как реакция на запрос клиента выполняется некий из методов объекта в этом rdm)

Вот это странно... У меня вроде асинхронно все шло, я же тестировал... Один клиент отправляет - второй получает, если метод сервера в это время не дергал

← →
Polevi © (2004-03-11 16:10) [13]

а если дергал

← →
Romkin © (2004-03-11 16:23) [14]

А если дергал - обработка пойдет после возврата из этого метода.

← →
Polevi © (2004-03-11 16:35) [15]

ладно, спорить не буду, но использовать данный код не рекомендую :-)
ты вот сам его сначала используй где нибудь :))

← →
Romkin © (2004-03-11 16:37) [16]

Вот еще :)) Я туда сначала малшалинг вмонтирую, с объектами - некрасиво ;)
Вот нужды до сих пор в таком не было...

← →
Dedushka_Mazai © (2004-03-16 13:47) [17]

Написал-таки колбэк, правда сделал это слегка не так, как описано в упомянутой выше статье: при коннекте каждого нового клиента передаю (как и было описано) интерфейс обратного вызова на сервер, потом делаю маршалинг интерфеса в стрим с помощью CoMarshalInterThreadInterfaceInStream. для отсылки сообщений обратно использую CoGetInterfaceAndReleaseStream для получения интерфейса из стрима, вызываю соотв. метод интерфейса и потом обратно сохраняю интерфейс в стрим. Вроде всё работает. Хотелось бы узнать мнение знающих людей обо всём этом.

совсем не понял причем тут маршалинг если честно
В варианте Romkin тоже "Вроде всё работает", до поры до времени

как это "причём"? чтобы сделать рассылку сообщений клиентам из одного места (из другого потока), а не создавать для каждого клиента доп. окно и отсылать сообщения в его WndProc-е, как сделал Romkin. Кстати, все тут хаили его код: "вот мол, всё это сомнительно и может не работать...", а никаких осмысленных замечаний никто не привёл

Ну да. Я тогда первый попавшийся способ синхронизации реализовал, так что все правильно, нафиг сообщения, все через интерфейсы надо делать

>Dedushka_Mazai © (16.03.04 15:19) [20]
я имел в виду что не важно каким способом делать на апп сервере - твоим или Romkin"a, проблема находится на уровне winsock транспорта данных, я в свое время очень конкретно изучал исходники и сделал для себя вывод. конкретно сказать не могу - надо вспоминать, давно это было

щас поднял нашь с Romkin спор годичной давности - в общем я пришел тогда к выводу что при такой системе возможен deadlock, когда клиентская и серверная части вызовут блокирующий winsock.send

то бишь, это есть бага BSS, как упоминалось выше?
а можно как-нибудь оценить вероятность возникновения такого дэдлока?

midas and callback Найти похожие ветки