Синхронизация с основным тредом программы не из TThread

← →
Дмитрий Белькевич (2011-06-14 19:29) [40]

> если один экземпляр, "апартмент" тип вроде то да, но "мульти"
> это отдельный инстанс в каждом потоке/подключении.

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

Или связка COM клиент-сервер создаётся на каждый поток приложения?

> прямой вызов функции и синхронно и ждет, и результат сразу.
> ..

Как на стороне сервера вызвать функцию клиента? Кроме событий я ничего не нашел.

Сейчас работает так:

COM сервер имеет COM интерфейс, через который его функции вызывает COM клиент.
COM сервер же через Events обращается к функциям клиента.

← →
Eraser © (2011-06-14 19:48) [41]

> Дмитрий Белькевич

вопрос. какой именно функционал надо реализовать? т.е. какова задача?

← →
sniknik © (2011-06-14 20:35) [42]

> Или связка COM клиент-сервер создаётся на каждый поток приложения?
само по себе ничего не создается, и то что ты в программе сделал хоть сто потоков, ни одного не создаст...

тебе не надоело абстракциями "швыряться"? мне попусту молоть уже да...

> Как на стороне сервера вызвать функцию клиента?
коллбек

> т.е. какова задача?
он считает, что уже все описал... -
>> Конкретный же вопрос.
при том, что методы о которых расспрашивает в ветке(2-х) уже раза четыре кардинально поменялись...

← →
Дмитрий Белькевич (2011-06-14 23:11) [43]

> вопрос. какой именно функционал надо реализовать? т.е. какова
> задача?

Есть некоторое количество функций в сервере и в клиенте, которые должны вызываться клиентом и сервером.

Действие первое. Сервер вызывает процедуру клиента. Клиент через var параметр синхронно возвращает результат вызова.

Действие второе. Клиент вызывает функцию сервера. Сервер возвращает результат функции.

Все действия независимы, их несколько разных - штук 30 первых и штук 40 вторых. Действия от клиента могут вызывать ответные действия от сервера до окончания вызова от клиента. Некоторые из первых действий идут из разных потоков, вторые идут из главного потока. Траффик как по вызовам, так и по объему данных, в обе стороны незначительный.

> он считает, что уже все описал... -

Я считаю, что задал достаточно конкретный первый вопрос. То, что все менялось - результат продолжения обсуждения вопроса в com/corba. Который там обсуждать никто не хотел (это я не предъявляю, просто констатирую - нету времени у людей, и мне никто не должен, я понимаю).

← →
Дмитрий Белькевич (2011-06-14 23:14) [44]

>Все действия независимы

в том смысле, что может одновременно (из разных тредов) прийти несколько первых действий.

← →
Eraser © (2011-06-14 23:23) [45]

> [43] Дмитрий Белькевич (14.06.11 23:11)

Оно конечно красиво звучит - "клиент вызывает код сервера". Но вот я бы лично такое реализовывать никогда бы не стал. Разве что, ради спорт. интереса. Оставим эту прерогативу монстрам типа MS. Не проще ли сделать обычный TCP или Named Pipe обмен данными? Если рассуждать более глобально, то я вообще не вижу смысла в нашу эпоху все строить исключительно на технологиях MS. А вдруг завтра клиент под айфон срочно писать, что тогда? Правильно - сервер тоже переписывать.

← →
Дмитрий Белькевич (2011-06-14 23:36) [46]

> Правильно - сервер тоже переписывать.

По хорошему-то, конечно, было б неплохо на трубы или сеть переползти, но возни много с параметрами, с синхронизацией ответов. Пока оставлю как есть. Может быть позже перелезу на что-то другое, пока немного сроки поджимают, хочется быстрое решение.
Жалко готовых библиотек нет (или не нашел), пусть и платных. Совсем нет времени заниматься транспортом данных, особенно учитывая, что в единственном месте пригодится.

> то я вообще не вижу смысла в нашу эпоху все строить исключительно
> на технологиях MS.

Да я и сам стараюсь максимально обходится без технологий MS, насколько это возможно и оправдано.

← →
sniknik © (2011-06-14 23:39) [47]

> Который там обсуждать никто не хотел ...
там тебе ОТВЕТИЛИ..., что ты проигнорировал, и начал нести свою "правду матку", в ответ проигнорировали тебя.

← →
Дмитрий Белькевич (2011-06-14 23:48) [48]

> и начал нести свою "правду матку"

Ну я там вроде бы ничего нигде не утверждал, только спрашивал.

← →
sniknik © (2011-06-15 00:18) [49]

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

ничего не напоминает?

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

и кстати ты проигнорировал мой ответ, про коллбеки (хоть что-то конкретное, среди абстракций, было на что ответить можно)...
вот +
http://www.rsdn.ru/article/db/callback.xml
и в общем то нафиг, эту ветку, уже тоже раздражать начинает. талант.

← →
Германн © (2011-06-15 01:09) [50]

> По хорошему-то, конечно, было б неплохо на трубы или сеть
> переползти, но возни много с параметрами, с синхронизацией
> ответов.

Имхо, тут непродуман некий "транспортный протокол". Оттуда ноги растут. И совсем не важно на какой основе сей "транспорт" реализован. И "синхронизация" тут тоже совсем не та, которая Synchronize.

← →
Eraser © (2011-06-15 05:07) [51]

> хочется быстрое решение

DCOM это быстрое решение?! да это думаю самое сложное решение из множества возможных.
На обычных Indy компонентах можно весьма быстро навоять универсальный многопоточный полнодуплексный транспорт сообщений. Для синхронизации с основным потоком можно делать выборку из очереди принятых по таймеру. Короче задача на пол дня, даже если не знаком с этими компонентами. Зачем же лезть в такие дебри как DCOM для простейших вещей.

← →
Дмитрий Белькевич (2011-06-15 23:43) [52]

> это ты вообще о чем? какая связь, из какого пальца синхронизацию
> высосал? и т.д. если бы была логическая цепочка процесса
> в твоей голове - "цикл выборки, как понял это синхронизация?
> т.к. выполнил код в ней и он заработал. значит нужно обязательно
> синхронизировать?"

Я понял, почему не работало. Собственно - написали - нет цикла сообщений. Спросил. Можно ли что-то сделать кроме синхронизации:

"Все события клиента нужно обязательно синхронизировать? Или можно как-то без этого обойтись?"

То есть - синхронизация с основным тредом - это единственно возможное решение? Или еще что-то возможно предпринять? В ответ - тишина.

После этого попытался выяснить каким боком вообще сообщения с COM связаны (кстати, до сих пор не знаю). Какое именно сообщение шлется основному потоку во время вызова COM Events в Synchronize? Кто это сообщение шлет? Какие параметры? Кто это сообщение позже обрабатывает?

> и кстати ты проигнорировал мой ответ, про коллбеки (хоть
> что-то конкретное, среди абстракций, было на что ответить
> можно)...

спасибо, посмотрю.

> И "синхронизация" тут тоже совсем не та, которая Synchronize

Само собой:

> DCOM это быстрое решение?!

Да.

Вообще, я пробовал пайпы - много работы (при том, что низкоуровневый транспорт уже работает нормально). DCOM за несколько дней заработал так, как ожидалось. В любом случае - я врятли сделали бы лучше, чем DCOM, и соединение было бы однопоточным - опять узкое место. Или пришлось бы распараллеливать на несколько пайпов, всё лишняя возня.

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

> Короче задача на пол дня

Увы, я не на столько крут :) Хоть и с компонентами знаком.

← →
Loginov Dmitry © (2011-06-16 00:20) [53]

> Несколько портов - хорошо, если они все будут свободными,
> если нет - придётся искать свободные.

А Вы считаете, что с DCOM ситуация лучше?
Дело до маразма доходит. DCOM выделяет прослушивающий порт случайным образом из некоторого (заранее неизвестного!) диапазона (якобы этот диапазон можно настраивать, но об этом я пока слышал только в теории). Это сделано с целью усиления защиты (хакеру трудно предугадать, какой набор портов используется в тот или иной момент DCOM-ом). Из-за этого невозможно настроить файрволл должным образом! DCOM-зло! Если этой поделкой пользуется MS, это не значит, что всем следует этим пользоваться.
Кстати Вы в курсе, что DataSnap в последних версиях Delphi уже не завязано на DCOM?

← →
Германн © (2011-06-16 02:02) [54]

> С tcp то же самое - через один порт параллельно несколько
> сообщений не передашь

А через что можно передать "параллельно несколько сообщений"?
Через DCOM? Ты либо бредишь, либо партизанишь.

← →
Eraser © (2011-06-16 03:17) [55]

если строго параллельно нужно передавать несколько сообщений, то скорее всего, ну в 95% случаев, нужно менять архитектуру. Насчет DCOM - есть еще такая замечательная вещь, как UAC и терминальные сессии. Короче, как говорится, не говорите потом, что я не предупреждал ;-)

← →
Eraser © (2011-06-16 03:26) [56]

> если строго параллельно нужно передавать несколько сообщений

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

← →
sniknik © (2011-06-16 08:19) [57]

> Я понял, почему не работало. Собственно - написали - нет цикла сообщений. Спросил. Можно ли что-то сделать кроме синхронизации:
понял? сомневаюсь... фразы строишь так как будто об одном и том же говоришь, а это РАЗНЫЕ вещи. и спрашиваешь дальше не о цикле, его ты игнорируешь, а о синхронизации.

типа
- я голоден.
- есть не пробовал?
- все поставленное на стол нужно выпить? нельзя без этого обойтись?
(жена ругает/с пол литры дурной становишься, и т.д. плевать на причины, сколько не обсуждай их потом/узнавай как "правильней", без болезненней, это НЕ ТО о чем тебе говорили изначально.)

p.s. вот как такой простой вещи не понять (РАЗНЫЕ!)... впечатление, как об стенку горох. глухо.

> В ответ - тишина.
я его понимаю... понять бессмысленность дальнейших объяснений по одной ответной реплике, и остановиться... тоже талант нужен.

← →
Дмитрий Белькевич (2011-06-16 09:48) [58]

> А через что можно передать "параллельно несколько сообщений"?
> Через DCOM? Ты либо бредишь, либо партизанишь.

Из того, что мне пытается объяснить sniknik, я делаю вывод - что да. Иначе я текущую реализацию трогать не буду, если всё равно всё в сериализацию запросов упрется.

← →
Дмитрий Белькевич (2011-06-16 10:31) [59]

> если строго параллельно нужно передавать несколько сообщений,
> то скорее всего, ну в 95% случаев, нужно менять архитектуру.
>

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

> Из того, что мне пытается объяснить sniknik, я делаю вывод - что да.
из какого места выводы?
я то думал, что объясняю разницу между решением проблемы, и решением "миража проблемы". впрочем... бессмысленно. нет даже первого шага - осознания, что разница вообще есть.

к тому же, если по мне, то решать нужно задачу а не проблемы на пути к ее решению... тут же вообще проблема выдумана (без кода это конечно догадки, предположения), но вот, что "имеем" взят COM/DCOM с событиями, то что по логике не требует потоков, просто даешь команду, оно выполняет независимо от тебя, по окончанию сигнализирует, обрабатываешь сигнал... все. эту событийную модель "ломают" под свое разумение т.к. "нужно ждать ответа" (кому нужно? это же логика, а не указ. ну да ладно), дальше "проблема", в основном потоке это "вешает" интерфейс... начинают "решать" пихают "систему" в поток... возникает вторая "проблема" поток "не ловит событий"... не разбираясь, и не даже пытаясь понять явную подсказку... "решили" "проблему" "выдавив" отлавливание события в основной поток, просто потому что "раз так работает, значит это то про, что сказали (цикл выборки)", теперь проблему уже не мелочах, теперь уже идеология, у человека (грубо) "еда" ассоциируется с "закусью при выпивке"... и т.д. ком проблем "из ничего". просто потому, что изначально выбрана не та модель/логика, что нужна (или вернее наоборот. не поняв "событийную логику" человек начал ее "ломать" вместо изучать, и понимать...)

и при том все в "абстракциях", спрашивает, что то, хочет совета "правильно ли делает", и все без строчки кода, как делается на самом деле... т.е. типа "верьте у меня правильно, не пойму только правильно ли будет добавить еще кусочек такого же правильного кода", ну типа того.

болтология одна, давно пора в потрепаться...

← →
Дмитрий Белькевич (2011-06-16 11:03) [61]

> из какого места выводы?

>> единомоментно COM передаёт только одно событие.
>если один экземпляр, "апартмент" тип вроде то да, но "мульти" это отдельный инстанс в каждом потоке/подключении.

> т.к. "нужно ждать ответа" (кому нужно? это же логика, а
> не указ. ну да ладно),

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

> дальше "проблема", в основном потоке это "вешает" интерфейс.
> ..

Я такого нигде не писал, у меня этой проблемы нет.

> начинают "решать" пихают "систему" в поток

Потоков много разных, к вешанью интерфейса и к интерфейсу вообще потоки никакого отношения не имеют. Потоки вообще без интерфейса могут работать. Сервису гуй вообще не обязателен. Гуй будет подключен - сервис "вывалит" на него, что с ним сейчас происходит, ну и даст поуправлять собой через гуй. Не будет - ну и ладно.

> просто потому что "раз так работает, значит это то про,
> что сказали (цикл выборки)",

Просто потому, что как ни сделай - всё равно так получится. В том смысле - что даже если я буду двигаться в направлении работы с циклом выборки - это ничего принципиально не изменит. Если COM сериализует вызовы.

> просто потому, что изначально выбрана не та модель/логика,
> что нужна (или вернее наоборот. не поняв "событийную логику"
> человек начал ее "ломать" вместо изучать, и понимать...)

Да знаю я событийную логику. Я понимаю, что русские любят всё переписывать с нуля, вместо того, что бы решать задачи минимальной кровью. Ну на кой ляд мне перелопачивать тысяч 200 строк кода, если и так всё работает как нужно? Только ради принципа "не так как у Архангельского"?

Модель работы выбиралась давно. Сейчас задача - с минимальными временными затратами и минимальными переделками разделить одно приложение на два - гуй + сервис.

>> единомоментно COM передаёт только одно событие.
>если один экземпляр, "апартмент" тип вроде то да, но "мульти" это отдельный инстанс в каждом потоке/подключении.
10 одновременно работающих экземпляров COM объекта трудно представить? а одновременно передаваемых от них событий? без демагогий о том что "на самом деле они не одновременные, а последовательные" просто событие либо ждет в очереди обработки предыдущего, либо получается инициировавшим его потоком.

> Нужно по логике работы программы. Да, она не асинхронно-событийная, она синхронная, так исторически сложилось.
тогда почему проигнорирован совет не пользоваться в потоках событийной моделью а просто сделать прямой вызов функции с возвратом из нее результата?

> Только ради принципа "не так как у Архангельского"?
ради принципа - "неправильное сделать правильным, или в корзину его". если работает и устраивает то в ж... принципы, просто не трогай работающее.

> разделить одно приложение на два - гуй + сервис.
удачи. она тебе понадобится.

> Сейчас задача - с минимальными временными затратами и минимальными
> переделками разделить одно приложение на два - гуй + сервис.
>

Для чего? Чем не устроило простое DCOM-приложение так, что потребовалось разбивать его на DCOM-приложение-сервис и интерфейс пользователя.
Кстати, на чем реализован DCOM-сервис? Случайно не через исходники службы "Borland Socket Server"? Если так, то от DCOM остается лишь одно название, получаем обычный TCP/IP.

> [61] Дмитрий Белькевич (16.06.11 11:03)

> гуй + сервис.

даже в ОС для этого используются именованные каналы.

← →
Дмитрий Белькевич (2011-06-19 11:56) [65]

> Чем не устроило простое DCOM-приложение так, что потребовалось
> разбивать его на DCOM-приложение-сервис и интерфейс пользователя.
>

Изначально приложение не было вообще DCOM. Изначально было просто обычное приложение - сервер. Который до win 2003 server можно было запустить как сервис (с помощью отдельной тулзы), взаимодействующий с пользователем. Всё всех устраивало и работало нормально. В 2008-м сервере от взаимодействия сервисов с пользователем отказались. Сервис взаимодействовать-то взаимодействует, только показывает всё на отдельном десктопе. Приходится разбивать приложение на два. Я не говорю, что это плохо (для буквоедов и иже), ну только что - лишняя возня.

> даже в ОС для этого используются именованные каналы.

Все меня так активно отговаривают от DCOM, почитал я ужасы DCOM в интернетах (Loginov Dmitr"ия в частности), что я опять на SOAP смотрю. Свой транспорт писать не хочу.

← →
Дмитрий Белькевич (2011-06-19 12:01) [66]

Интересно как у SOAP с двухсторонним общением...

> Все меня так активно отговаривают от DCOM, почитал я ужасы
> DCOM в интернетах (Loginov Dmitr"ия в частности), что я
> опять на SOAP смотрю.

От DCOM"а никто не отговаривает. Если приложение уже написано и работает, то менять что-то из-за вычитанных "ужасов" - нецелесообразно. Но при разработке нового приложения я бы рекомендовал учитывать мнения, здесь высказанные.

← →
DCOM (2011-06-19 17:04) [68]

DCOM<>COM

Синхронизация с основным тредом программы не из TThread Найти похожие ветки