| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
midas and callback [D7]
Dedushka_Mazai © (2004-03-11 14:00:00)как можно организовать callback для трёхзвенки (tsocketconnection)?
Dedushka_Mazai (2004-03-16 18:07:00) [1]то бишь, это есть бага BSS, как упоминалось выше?
а можно как-нибудь оценить вероятность возникновения такого дэдлока?
Polevi (2004-03-16 17:54:00) [2]щас поднял нашь с Romkin спор годичной давности - в общем я пришел тогда к выводу что при такой системе возможен deadlock, когда клиентская и серверная части вызовут блокирующий winsock.send
Polevi (2004-03-16 17:39:00) [3]>Dedushka_Mazai © (16.03.04 15:19) [20]
я имел в виду что не важно каким способом делать на апп сервере - твоим или Romkin'a, проблема находится на уровне winsock транспорта данных, я в свое время очень конкретно изучал исходники и сделал для себя вывод. конкретно сказать не могу - надо вспоминать, давно это было
Romkin (2004-03-16 15:30:00) [4]Ну да. Я тогда первый попавшийся способ синхронизации реализовал, так что все правильно, нафиг сообщения, все через интерфейсы надо делать
Dedushka_Mazai (2004-03-16 15:19:00) [5]как это "причём"? чтобы сделать рассылку сообщений клиентам из одного места (из другого потока), а не создавать для каждого клиента доп. окно и отсылать сообщения в его WndProc-е, как сделал Romkin. Кстати, все тут хаили его код: "вот мол, всё это сомнительно и может не работать...", а никаких осмысленных замечаний никто не привёл
Polevi (2004-03-16 14:52:00) [6]совсем не понял причем тут маршалинг если честно
В варианте Romkin тоже "Вроде всё работает", до поры до времени
Dedushka_Mazai (2004-03-16 13:48:00) [7]Написал-таки колбэк, правда сделал это слегка не так, как описано в упомянутой выше статье: при коннекте каждого нового клиента передаю (как и было описано) интерфейс обратного вызова на сервер, потом делаю маршалинг интерфеса в стрим с помощью CoMarshalInterThreadInterfaceInStream. для отсылки сообщений обратно использую CoGetInterfaceAndReleaseStream для получения интерфейса из стрима, вызываю соотв. метод интерфейса и потом обратно сохраняю интерфейс в стрим. Вроде всё работает. Хотелось бы узнать мнение знающих людей обо всём этом.
Dedushka_Mazai (2004-03-16 13:47:00) [8]Написал-таки колбэк, правда сделал это слегка не так, как описано в упомянутой выше статье: при коннекте каждого нового клиента передаю (как и было описано) интерфейс обратного вызова на сервер, потом делаю маршалинг интерфеса в стрим с помощью CoMarshalInterThreadInterfaceInStream. для отсылки сообщений обратно использую CoGetInterfaceAndReleaseStream для получения интерфейса из стрима, вызываю соотв. метод интерфейса и потом обратно сохраняю интерфейс в стрим. Вроде всё работает. Хотелось бы узнать мнение знающих людей обо всём этом.
Romkin (2004-03-11 16:37:00) [9]Вот еще :)) Я туда сначала малшалинг вмонтирую, с объектами - некрасиво ;)
Вот нужды до сих пор в таком не было...
Polevi (2004-03-11 16:35:00) [10]ладно, спорить не буду, но использовать данный код не рекомендую :-)
ты вот сам его сначала используй где нибудь :))
Romkin (2004-03-11 16:23:00) [11]А если дергал - обработка пойдет после возврата из этого метода.
Polevi (2004-03-11 16:10:00) [12]а если дергал
Romkin (2004-03-11 15:19:00) [13]>т.е. вызывающий поток клиента сделал запрос (callsig) и ждет результата (resultsig) .. вместо этого он в ответ может получить кучу callsig-пакетов и вынужден их обрабатывать и возвращать resultsig
Нет, на клиенте коллбек получается в другом потоке, и синхронизируется сообщением. То есть пока основной поток чего-то ждет - ничего он не получит. Только при выборке сообщений.
>к тому же rdm , работающий под контролем BSS, не имеет возможности инициировать колбэк асинхронно, в произвольный момент времени (только в момент времени, когда как реакция на запрос клиента выполняется некий из методов объекта в этом rdm)
Вот это странно... У меня вроде асинхронно все шло, я же тестировал... Один клиент отправляет - второй получает, если метод сервера в это время не дергал
Digitman (2004-03-11 15:09:00) [14]
> Romkin © (11.03.04 14:49) [8]
> Это о том, что на клиенте обратный вызов в основной поток
> идет?
основной или не основной - не важно ... в вызывающий ..
т.е. вызывающий поток клиента сделал запрос (callsig) и ждет результата (resultsig) .. вместо этого он в ответ может получить кучу callsig-пакетов и вынужден их обрабатывать и возвращать resultsig
к тому же rdm , работающий под контролем BSS, не имеет возможности инициировать колбэк асинхронно, в произвольный момент времени (только в момент времени, когда как реакция на запрос клиента выполняется некий из методов объекта в этом rdm)
Romkin (2004-03-11 15:00:00) [15]Дык надо было оттрассировать, и исправление - в комментарии :)
Nikolay M. (2004-03-11 14:51:00) [16]
> Polevi © (11.03.04 14:34) [6]
> у меня вообще есть подозрения что при определенных условиях
> этот код не будет работать
Подтверждаю (чисто из практики). Просто нагло содрал код один в один, встроил в свою программу как фичу менеджерам для обмена сообщениями. Иногда сообщение уходило в никуда без каких бы то ни было ошибок.
Romkin (2004-03-11 14:49:00) [17]А фиг его знает :((
Я так и не дошел до реальной реализации.
>сериализация в контексте одного и того же код.потока накладывает серьезные ограничения.. потому и упомянул о необходимости переделки BSS
Это о том, что на клиенте обратный вызов в основной поток идет? На мой взгляд, удобно.
Интересно, и при каких условиях работать не будет?
Digitman (2004-03-11 14:38:00) [18]
> Polevi © (11.03.04 14:34) [6]
и они вполне оправданы
Polevi (2004-03-11 14:34:00) [19]у меня вообще есть подозрения что при определенных условиях этот код не будет работать
Digitman (2004-03-11 14:30:00) [20]
> Romkin © (11.03.04 14:15) [3]
я видел этот код
согласись, это - эрзац-колбэк, а не настоящий колбэк ...
сериализация в контексте одного и того же код.потока накладывает серьезные ограничения.. потому и упомянул о необходимости переделки BSS
| |
Страницы: 