На сервере есть несколько операций, которые выполняются очень долго, поэтому нужно реализовать некоторое подобие многопоточноти. Как я понимаю, можно использовать Free-Threaded Model (MTA), но чего-то оно не получается. Точнее, если у меня сервер с виде DLL, то несколько потоков, созданных в данном процессе без проблем выполняют параллельно одни и те же методы интерфейса. Но у меня сервер реализован в виде EXE и поэтому каждый клиент — это другой процесс и вызовы серверов почему-то синхронизируется (то есть пока метод выполняется одним из клиентов, то другой клиент не может даже указатель на интерфейс получить). В чем может быть дело?
P.S. Может написать новую фабрику классов и каждый раз при запросе интерфейса создавать новый экземпляр объекта?
Здравствуйте Аноним, Вы писали:
А>На сервере есть несколько операций, которые выполняются очень долго, поэтому нужно реализовать некоторое подобие многопоточноти. Как я понимаю, можно использовать Free-Threaded Model (MTA), но чего-то оно не получается. Точнее, если у меня сервер с виде DLL, то несколько потоков, созданных в данном процессе без проблем выполняют параллельно одни и те же методы интерфейса. Но у меня сервер реализован в виде EXE и поэтому каждый клиент — это другой процесс и вызовы серверов почему-то синхронизируется (то есть пока метод выполняется одним из клиентов, то другой клиент не может даже указатель на интерфейс получить). В чем может быть дело? А>P.S. Может написать новую фабрику классов и каждый раз при запросе интерфейса создавать новый экземпляр объекта?
Странное дело легаси (гы MS так теперь старые DCOM.EXE-шные сервера называет) вроде как работал неплохо. Тут на код бы взглянуть. В инпроце все может бить совсем сложно, тут нужно смотреть как создаются потоки, как они инициализируются и как маршалятся указатели на интерфейсы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Множество клиентов на один сервер.
От:
Аноним
Дата:
05.11.01 04:05
Оценка:
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте Аноним, Вы писали:
А>>На сервере есть несколько операций, которые выполняются очень долго, поэтому нужно реализовать некоторое подобие многопоточноти. Как я понимаю, можно использовать Free-Threaded Model (MTA), но чего-то оно не получается. Точнее, если у меня сервер с виде DLL, то несколько потоков, созданных в данном процессе без проблем выполняют параллельно одни и те же методы интерфейса. Но у меня сервер реализован в виде EXE и поэтому каждый клиент — это другой процесс и вызовы серверов почему-то синхронизируется (то есть пока метод выполняется одним из клиентов, то другой клиент не может даже указатель на интерфейс получить). В чем может быть дело? А>>P.S. Может написать новую фабрику классов и каждый раз при запросе интерфейса создавать новый экземпляр объекта?
VD>Странное дело легаси (гы MS так теперь старые DCOM.EXE-шные сервера называет) вроде как работал неплохо. Тут на код бы взглянуть. В инпроце все может бить совсем сложно, тут нужно смотреть как создаются потоки, как они инициализируются и как маршалятся указатели на интерфейсы.
Никакие потоки не создаются и никакие интерфейсы не маршалятся. Все просто и не интересно: на сервере создается Free Model сервер. Клиент делает CoInitialize[Ex] и CoCreateInstance[Ex], после чего запускается два экземпляра клиента и в результате выходит, что один ждет другого.
А вообще я тут потыкался-потыкался и начинаю понимать, что наверное такое вообще невозможно. Точнее, на такую мысль меня навела MSDN, в которой это очень сумрачно упоминается. Или я не прав? Просвятите пожалуйста или дайте простейший исходник, в котром все работает.
Здравствуйте Аноним, Вы писали:
А>Никакие потоки не создаются и никакие интерфейсы не маршалятся. Все просто и не интересно: на сервере создается Free Model сервер.
^^^^^^^^^^^^^^^^^^^^^^^^^^^
Как это делается в вашем EXE-сервере?
А>Клиент делает CoInitialize[Ex] и CoCreateInstance[Ex], после чего запускается два экземпляра клиента и в результате выходит, что один ждет другого. А>А вообще я тут потыкался-потыкался и начинаю понимать, что наверное такое вообще невозможно. Точнее, на такую мысль меня навела MSDN, в которой это очень сумрачно упоминается. Или я не прав? Просвятите пожалуйста или дайте простейший исходник, в котром все работает.
Здравствуйте Аноним, Вы писали:
А>Никакие потоки не создаются и никакие интерфейсы не маршалятся. Все просто и не интересно: на сервере создается Free Model сервер. Клиент делает CoInitialize[Ex] и CoCreateInstance[Ex], после чего запускается два экземпляра клиента и в результате выходит, что один ждет другого. А>А вообще я тут потыкался-потыкался и начинаю понимать, что наверное такое вообще невозможно. Точнее, на такую мысль меня навела MSDN, в которой это очень сумрачно упоминается. Или я не прав? Просвятите пожалуйста или дайте простейший исходник, в котром все работает.
Свою длительную операцию запихни в поток. Естественно клиенты будут
ждать друг друга, процесс же на сервере один.
Здравствуйте Аноним, Вы писали:
А>На сервере есть несколько операций, которые выполняются очень долго, поэтому нужно реализовать некоторое подобие многопоточноти. Как я понимаю, можно использовать Free-Threaded Model (MTA), но чего-то оно не получается. Точнее, если у меня сервер с виде DLL, то несколько потоков, созданных в данном процессе без проблем выполняют параллельно одни и те же методы интерфейса. Но у меня сервер реализован в виде EXE и поэтому каждый клиент — это другой процесс и вызовы серверов почему-то синхронизируется (то есть пока метод выполняется одним из клиентов, то другой клиент не может даже указатель на интерфейс получить). В чем может быть дело? А>P.S. Может написать новую фабрику классов и каждый раз при запросе интерфейса создавать новый экземпляр объекта?
Как на сервере происходит инициализация COM?
Для того, чтобы реализовать Free-Threaded сервер в EXE,
необходимо инициализировать COM строкой
CoInitializeEx(COINIT_MULTITHREADED);
Здравствуйте Аноним, Вы писали:
А>Никакие потоки не создаются и никакие интерфейсы не маршалятся. Все просто и не интересно: на сервере создается Free Model сервер.
ATL-ный сервер с установками по умолчанию?
А>Клиент делает CoInitialize[Ex] и CoCreateInstance[Ex], после чего запускается два экземпляра клиента и в результате выходит, что один ждет другого.
Вроде работает как надо. При его дапуске надо убетиться, что сервер может взаимодействовать с клиентом, так как в методе сервера вызывается банальный MessageBox. При запуске на одной машине все должно работать. Клиент написан на VB. Лежит тамже.
А>А вообще я тут потыкался-потыкался и начинаю понимать, что наверное такое вообще невозможно. Точнее, на такую мысль меня навела MSDN, в которой это очень сумрачно упоминается. Или я не прав? Просвятите пожалуйста или дайте простейший исходник, в котром все работает.
Ничего подобного не видел. Если можно, цитату...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте Dima2, Вы писали:
D>>Свою длительную операцию запихни в поток. Естественно клиенты будут D>>ждать друг друга, процесс же на сервере один.
VD>А что у нас теперь Win32-процессы научились исполнять код?
Не надо придираться к словам. Процессы не исполняют код.
Код исполняет задача (thread, поток) этого процесса.
Я это имел ввиду.
Здравствуйте Dima2, Вы писали:
D>Не надо придираться к словам. Процессы не исполняют код. D>Код исполняет задача (thread, поток) этого процесса. D>Я это имел ввиду.
OK! Но тогда переведи плз. это:
D>>>Свою длительную операцию запихни в поток. Естественно клиенты будут D>>>ждать друг друга, процесс же на сервере один.
Нет ощущения что подмена понятия поток/процесс привела к неправильному выводу?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, Вы писали:
VD>OK! Но тогда переведи плз. это:
D>>>>Свою длительную операцию запихни в поток. Естественно клиенты будут D>>>>ждать друг друга, процесс же на сервере один.
VD>Нет ощущения что подмена понятия поток/процесс привела к неправильному выводу?
Согласен, надо дописать одно слово.
Свою длительную операцию запихни в н о в ы й поток.
Слово процесс заменить на поток.
Здравствуйте VladD2, Вы писали:
VD>Вроде работает как надо. При его дапуске надо убетиться, что сервер может взаимодействовать с клиентом, так как в методе сервера вызывается банальный MessageBox. При запуске на одной машине все должно работать. Клиент написан на VB. Лежит тамже.
MessageBox в данном случае не пойдет для примера, т. к. не блокируется обработка сообщений RPC hidden-окном апартамента. Попробуй вместо MessageBox поставить Sleep, и ты увидишь, что тормоза начнутся.
Здравствуйте serg_mo, Вы писали:
SM>MessageBox в данном случае не пойдет для примера, т. к. не блокируется обработка сообщений RPC hidden-окном апартамента. Попробуй вместо MessageBox поставить Sleep, и ты увидишь, что тормоза начнутся.
А я вчера кстати уже попробовал в примере VladD2 заменить
MessageBox на Sleep. Все равно работает. Тормозит только
тот клиент, который вызвал ф-и со Sleep. Второй клиент
нормально может вызывать другие ф-ии сервера.
Здравствуйте Dima2, Вы писали:
D>А я вчера кстати уже попробовал в примере VladD2 заменить D>MessageBox на Sleep. Все равно работает. Тормозит только D>тот клиент, который вызвал ф-и со Sleep. Второй клиент D>нормально может вызывать другие ф-ии сервера.
Прошу прощения, только что скачал пример и посмотрел его. Действительно, в данной
ситуации реализован Free-Threaded EXE сервер. Достаточно просто взглянуть в stdafx.h
и увидеть строку
Здравствуйте IT, Вы писали:
IT>Здравствуйте Dima2, Вы писали:
D>>VladD2, а ты корректором ни когда не работал :)
IT>Хорошая шутка :) IT>А ты к нему в профайл загляни — http://www.rsdn.ru/users/profile.asp?uid=73 ;)
:) Но корректором мне нельзя. Я даже если знаю как правильно писать все равно сделаю 10 ошибок в слове из 5-и бикв. :))
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте serg_mo, Вы писали:
SM>Прошу прощения, только что скачал пример и посмотрел его. Действительно, в данной SM>ситуации реализован Free-Threaded EXE сервер. Достаточно просто взглянуть в stdafx.h SM>и увидеть строку
SM>#define _ATL_FREE_THREADED
SM>которой вполне достаточно :))))
Я так понял, что проблема решена? И заключалась в _ATL_FREE_THREADED?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Если нам не помогут, то мы тоже никого не пощадим.
