| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Синхронизация с основным тредом программы не из TThread
Дмитрий Белькевич © (2011-06-09 15:48:00)Добрый день. С синхронизацией из TThread, в целом, все понятно. Как сделать синхронизацию с основным тредом из треда, от которого есть только Idшник: GetCurrentThreadId?
DCOM (2011-06-19 17:04:00) [1]DCOM<>COM
Loginov Dmitry (2011-06-19 15:08:00) [2]
> Все меня так активно отговаривают от DCOM, почитал я ужасы
> DCOM в интернетах (Loginov Dmitr'ия в частности), что я
> опять на SOAP смотрю.
От DCOM'а никто не отговаривает. Если приложение уже написано и работает, то менять что-то из-за вычитанных "ужасов" - нецелесообразно. Но при разработке нового приложения я бы рекомендовал учитывать мнения, здесь высказанные.
Дмитрий Белькевич (2011-06-19 12:01:00) [3]Интересно как у SOAP с двухсторонним общением...
Дмитрий Белькевич (2011-06-19 11:56:00) [4]
> Чем не устроило простое DCOM-приложение так, что потребовалось
> разбивать его на DCOM-приложение-сервис и интерфейс пользователя.
>
Изначально приложение не было вообще DCOM. Изначально было просто обычное приложение - сервер. Который до win 2003 server можно было запустить как сервис (с помощью отдельной тулзы), взаимодействующий с пользователем. Всё всех устраивало и работало нормально. В 2008-м сервере от взаимодействия сервисов с пользователем отказались. Сервис взаимодействовать-то взаимодействует, только показывает всё на отдельном десктопе. Приходится разбивать приложение на два. Я не говорю, что это плохо (для буквоедов и иже), ну только что - лишняя возня.
> даже в ОС для этого используются именованные каналы.
Все меня так активно отговаривают от DCOM, почитал я ужасы DCOM в интернетах (Loginov Dmitr'ия в частности), что я опять на SOAP смотрю. Свой транспорт писать не хочу.
Eraser (2011-06-17 05:53:00) [5]> [61] Дмитрий Белькевич (16.06.11 11:03)
> гуй + сервис.
даже в ОС для этого используются именованные каналы.
Loginov Dmitry (2011-06-16 21:58:00) [6]
> Сейчас задача - с минимальными временными затратами и минимальными
> переделками разделить одно приложение на два - гуй + сервис.
>
Для чего? Чем не устроило простое DCOM-приложение так, что потребовалось разбивать его на DCOM-приложение-сервис и интерфейс пользователя.
Кстати, на чем реализован DCOM-сервис? Случайно не через исходники службы "Borland Socket Server"? Если так, то от DCOM остается лишь одно название, получаем обычный TCP/IP.
sniknik (2011-06-16 11:47:00) [7]>> единомоментно COM передаёт только одно событие.
>если один экземпляр, "апартмент" тип вроде то да, но "мульти" это отдельный инстанс в каждом потоке/подключении.
10 одновременно работающих экземпляров COM объекта трудно представить? а одновременно передаваемых от них событий? без демагогий о том что "на самом деле они не одновременные, а последовательные" просто событие либо ждет в очереди обработки предыдущего, либо получается инициировавшим его потоком.
> Нужно по логике работы программы. Да, она не асинхронно-событийная, она синхронная, так исторически сложилось.
тогда почему проигнорирован совет не пользоваться в потоках событийной моделью а просто сделать прямой вызов функции с возвратом из нее результата?
> Только ради принципа 'не так как у Архангельского'?
ради принципа - "неправильное сделать правильным, или в корзину его". если работает и устраивает то в ж... принципы, просто не трогай работающее.
> разделить одно приложение на два - гуй + сервис.
удачи. она тебе понадобится.
Дмитрий Белькевич (2011-06-16 11:03:00) [8]
> из какого места выводы?
>> единомоментно COM передаёт только одно событие.
>если один экземпляр, "апартмент" тип вроде то да, но "мульти" это отдельный инстанс в каждом потоке/подключении.
> т.к. "нужно ждать ответа" (кому нужно? это же логика, а
> не указ. ну да ладно),
Нужно по логике работы программы. Да, она не асинхронно-событийная, она синхронная, так исторически сложилось.
> дальше "проблема", в основном потоке это "вешает" интерфейс.
> ..
Я такого нигде не писал, у меня этой проблемы нет.
> начинают "решать" пихают "систему" в поток
Потоков много разных, к вешанью интерфейса и к интерфейсу вообще потоки никакого отношения не имеют. Потоки вообще без интерфейса могут работать. Сервису гуй вообще не обязателен. Гуй будет подключен - сервис 'вывалит' на него, что с ним сейчас происходит, ну и даст поуправлять собой через гуй. Не будет - ну и ладно.
> просто потому что "раз так работает, значит это то про,
> что сказали (цикл выборки)",
Просто потому, что как ни сделай - всё равно так получится. В том смысле - что даже если я буду двигаться в направлении работы с циклом выборки - это ничего принципиально не изменит. Если COM сериализует вызовы.
> просто потому, что изначально выбрана не та модель/логика,
> что нужна (или вернее наоборот. не поняв "событийную логику"
> человек начал ее "ломать" вместо изучать, и понимать...)
Да знаю я событийную логику. Я понимаю, что русские любят всё переписывать с нуля, вместо того, что бы решать задачи минимальной кровью. Ну на кой ляд мне перелопачивать тысяч 200 строк кода, если и так всё работает как нужно? Только ради принципа 'не так как у Архангельского'?
Модель работы выбиралась давно. Сейчас задача - с минимальными временными затратами и минимальными переделками разделить одно приложение на два - гуй + сервис.
sniknik (2011-06-16 10:34:00) [9]> Из того, что мне пытается объяснить sniknik, я делаю вывод - что да.
из какого места выводы?
я то думал, что объясняю разницу между решением проблемы, и решением "миража проблемы". впрочем... бессмысленно. нет даже первого шага - осознания, что разница вообще есть.
к тому же, если по мне, то решать нужно задачу а не проблемы на пути к ее решению... тут же вообще проблема выдумана (без кода это конечно догадки, предположения), но вот, что "имеем" взят COM/DCOM с событиями, то что по логике не требует потоков, просто даешь команду, оно выполняет независимо от тебя, по окончанию сигнализирует, обрабатываешь сигнал... все. эту событийную модель "ломают" под свое разумение т.к. "нужно ждать ответа" (кому нужно? это же логика, а не указ. ну да ладно), дальше "проблема", в основном потоке это "вешает" интерфейс... начинают "решать" пихают "систему" в поток... возникает вторая "проблема" поток "не ловит событий"... не разбираясь, и не даже пытаясь понять явную подсказку... "решили" "проблему" "выдавив" отлавливание события в основной поток, просто потому что "раз так работает, значит это то про, что сказали (цикл выборки)", теперь проблему уже не мелочах, теперь уже идеология, у человека (грубо) "еда" ассоциируется с "закусью при выпивке"... и т.д. ком проблем "из ничего". просто потому, что изначально выбрана не та модель/логика, что нужна (или вернее наоборот. не поняв "событийную логику" человек начал ее "ломать" вместо изучать, и понимать...)
и при том все в "абстракциях", спрашивает, что то, хочет совета "правильно ли делает", и все без строчки кода, как делается на самом деле... т.е. типа "верьте у меня правильно, не пойму только правильно ли будет добавить еще кусочек такого же правильного кода", ну типа того.
болтология одна, давно пора в потрепаться...
Дмитрий Белькевич (2011-06-16 10:31:00) [10]
> если строго параллельно нужно передавать несколько сообщений,
> то скорее всего, ну в 95% случаев, нужно менять архитектуру.
>
Мне - не нужно, мне пытаются объяснить, что так - единственно хорошо. Меня, в общем, и последовательные запросы устраивают вполне. Треды немного подождут - не беда.
Дмитрий Белькевич (2011-06-16 09:48:00) [11]
> А через что можно передать "параллельно несколько сообщений"?
> Через DCOM? Ты либо бредишь, либо партизанишь.
Из того, что мне пытается объяснить sniknik, я делаю вывод - что да. Иначе я текущую реализацию трогать не буду, если всё равно всё в сериализацию запросов упрется.
sniknik (2011-06-16 08:19:00) [12]> Я понял, почему не работало. Собственно - написали - нет цикла сообщений. Спросил. Можно ли что-то сделать кроме синхронизации:
понял? сомневаюсь... фразы строишь так как будто об одном и том же говоришь, а это РАЗНЫЕ вещи. и спрашиваешь дальше не о цикле, его ты игнорируешь, а о синхронизации.
типа
- я голоден.
- естьне пробовал?
- все поставленное на стол нужно выпить? нельзя без этого обойтись?
(жена ругает/с пол литры дурной становишься, и т.д. плевать на причины, сколько не обсуждай их потом/узнавай как "правильней", без болезненней, это НЕ ТО о чем тебе говорили изначально.)
p.s. вот как такой простой вещи не понять (РАЗНЫЕ!)... впечатление, как об стенку горох. глухо.
> В ответ - тишина.
я его понимаю... понять бессмысленность дальнейших объяснений по одной ответной реплике, и остановиться... тоже талант нужен.
Eraser (2011-06-16 03:26:00) [13]> если строго параллельно нужно передавать несколько сообщений
для буквоедов поясню, что имеется ввиду не одновременная работа нескольких сетевых потоков или очередей, а именно строго синхронизированная друг с другом одновременная отправка сообщений по сети.
Eraser (2011-06-16 03:17:00) [14]если строго параллельно нужно передавать несколько сообщений, то скорее всего, ну в 95% случаев, нужно менять архитектуру. Насчет DCOM - есть еще такая замечательная вещь, как UAC и терминальные сессии. Короче, как говорится, не говорите потом, что я не предупреждал ;-)
Германн (2011-06-16 02:02:00) [15]
> С tcp то же самое - через один порт параллельно несколько
> сообщений не передашь
А через что можно передать "параллельно несколько сообщений"?
Через DCOM? Ты либо бредишь, либо партизанишь.
Loginov Dmitry (2011-06-16 00:20:00) [16]
> Несколько портов - хорошо, если они все будут свободными,
> если нет - придётся искать свободные.
А Вы считаете, что с DCOM ситуация лучше?
Дело до маразма доходит. DCOM выделяет прослушивающий порт случайным образом из некоторого (заранее неизвестного!) диапазона (якобы этот диапазон можно настраивать, но об этом я пока слышал только в теории). Это сделано с целью усиления защиты (хакеру трудно предугадать, какой набор портов используется в тот или иной момент DCOM-ом). Из-за этого невозможно настроить файрволл должным образом! DCOM-зло! Если этой поделкой пользуется MS, это не значит, что всем следует этим пользоваться.
Кстати Вы в курсе, что DataSnap в последних версиях Delphi уже не завязано на DCOM?
Дмитрий Белькевич (2011-06-15 23:43:00) [17]
> это ты вообще о чем? какая связь, из какого пальца синхронизацию
> высосал? и т.д. если бы была логическая цепочка процесса
> в твоей голове - "цикл выборки, как понял это синхронизация?
> т.к. выполнил код в ней и он заработал. значит нужно обязательно
> синхронизировать?"
Я понял, почему не работало. Собственно - написали - нет цикла сообщений. Спросил. Можно ли что-то сделать кроме синхронизации:
"Все события клиента нужно обязательно синхронизировать? Или можно как-то без этого обойтись?"
То есть - синхронизация с основным тредом - это единственно возможное решение? Или еще что-то возможно предпринять? В ответ - тишина.
После этого попытался выяснить каким боком вообще сообщения с COM связаны (кстати, до сих пор не знаю). Какое именно сообщение шлется основному потоку во время вызова COM Events в Synchronize? Кто это сообщение шлет? Какие параметры? Кто это сообщение позже обрабатывает?
> и кстати ты проигнорировал мой ответ, про коллбеки (хоть
> что-то конкретное, среди абстракций, было на что ответить
> можно)...
спасибо, посмотрю.
> И "синхронизация" тут тоже совсем не та, которая Synchronize
Само собой:
> DCOM это быстрое решение?!
Да.
Вообще, я пробовал пайпы - много работы (при том, что низкоуровневый транспорт уже работает нормально). DCOM за несколько дней заработал так, как ожидалось. В любом случае - я врятли сделали бы лучше, чем DCOM, и соединение было бы однопоточным - опять узкое место. Или пришлось бы распараллеливать на несколько пайпов, всё лишняя возня.
С tcp то же самое - через один порт параллельно несколько сообщений не передашь - только если несколько соединений делать. Всё равно возвращаемся к сериализации запросов в обе стороны - никаких преимуществ по сравнению с тем, как уже сделано (ну разве что не будет привязки к COM). Несколько портов - хорошо, если они все будут свободными, если нет - придётся искать свободные. Ну это то, что сразу могу придумать, что придется обрабатывать.
> Короче задача на пол дня
Увы, я не на столько крут :) Хоть и с компонентами знаком.
Eraser (2011-06-15 05:07:00) [18]> хочется быстрое решение
DCOM это быстрое решение?! да это думаю самое сложное решение из множества возможных.
На обычных Indy компонентах можно весьма быстро навоять универсальный многопоточный полнодуплексный транспорт сообщений. Для синхронизации с основным потоком можно делать выборку из очереди принятых по таймеру. Короче задача на пол дня, даже если не знаком с этими компонентами. Зачем же лезть в такие дебри как DCOM для простейших вещей.
Германн (2011-06-15 01:09:00) [19]
> По хорошему-то, конечно, было б неплохо на трубы или сеть
> переползти, но возни много с параметрами, с синхронизацией
> ответов.
Имхо, тут непродуман некий "транспортный протокол". Оттуда ноги растут. И совсем не важно на какой основе сей "транспорт" реализован. И "синхронизация" тут тоже совсем не та, которая Synchronize.
sniknik (2011-06-15 00:18:00) [20]был такой рецепт (не помню, что то вроде "вредных советов") - как, просто, взбесить человека...
ответ
разговаривайте с ним "невпопад", т.е. типа на вопрос типа
- ты пойдешь сегодня в кино.
- спасибо я уже пообедал.
или
- В неосновном потоке, конечно же, цикла выборки сообщений нет.
- Все события клиента нужно обязательно синхронизировать? Или можно как-то без этого обойтись?
ничего не напоминает?
это ты вообще о чем? какая связь, из какого пальца синхронизацию высосал? и т.д. если бы была логическая цепочка процесса в твоей голове - "цикл выборки, как понял это синхронизация? т.к. выполнил код в ней и он заработал. значит нужно обязательно синхронизировать?"
и тебе бы ответили "нет, это вообще не связано, а работает потому, что при синхронизации код выполняется в основном потоке, а там цикл есть."
но ты видимо считаешь свои выводы безупречными, то к чему они привели единственно верным (при отсутствии знаний по вопросу, да это батенька мания величия...), поэтому "режешь" конечным результатом своей мозговой деятельности... и попадаешь невпопад... прямо по "вредным советам"...
и кстати ты проигнорировал мой ответ, про коллбеки (хоть что-то конкретное, среди абстракций, было на что ответить можно)...
вот +
http://www.rsdn.ru/article/db/callback.xml
и в общем то нафиг, эту ветку, уже тоже раздражать начинает. талант.
| |
Страницы: 