Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2007.04.01;
Скачать: CL | DM;

Вниз

Indy10 + Thread   Найти похожие ветки 

 
Lilu   (2006-10-17 10:08) [0]

Подскажите пожалуйста как синхронизировать потоки главный и idServerExecute (indy 10). Если синхронайзом, то где в idServer-е тот поток котрый активный?


 
Орион ©   (2006-10-17 10:10) [1]

TCriticalSection?


 
Lilu   (2006-10-17 10:39) [2]


> TCriticalSection?

а как обратиться к потоку, созданному при connect-е idServer-а ?


 
Сергей М. ©   (2006-10-17 11:23) [3]


> Lilu   (17.10.06 10:39) [2]


Как в 10-ке - не знаю, а в 9-ке обработчик OnExecute вызывается с параметром AThread: TIdPeerThread, это и есть искомый поток.

Только вот к его Synchronize-методу добраться просто так не удастся - метод этот, как известно, protected. Придется писать и задействовать свой менеджер потоков (см. св-во TIdTCPServer.ThreadMgr). Гораздо проще будет осуществлять синхронизацию доп.потока с осн.потоком отправкой синхр.сообщений окну осн.потока.


 
umbra ©   (2006-10-17 11:29) [4]

в обработчик события OnConnect передается параметр Context, через который и можно обратиться к потоку , который создается при коннекте


 
Сергей М. ©   (2006-10-17 11:46) [5]


> umbra ©   (17.10.06 11:29) [4]


> который создается при коннекте


Точнее - берется у ThreadMgr"а (новый или один из уже существующих и свободных в пуле)


 
Lilu   (2006-10-17 11:49) [6]


> в обработчик события OnConnect передается параметр Context,
>  через который и можно обратиться к потоку , который создается
> при коннекте

AContext: TIdContext

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


 
Lilu   (2006-10-17 11:53) [7]

Сергей М. , 9 с 10 сильно различаются :(


 
Сергей М. ©   (2006-10-17 12:03) [8]


> Lilu   (17.10.06 11:53) [7]


Не суть как важно.
И там и там есть доп.потоки, ассоциированные с активными соединениями.


 
Lilu   (2006-10-17 12:06) [9]

Я не понимаю почему этот вопрос нигде не освещен :(
у меня есть idTCPServer, функции которого- принять инфу и запихать ее в БД.
Методы работы с БД лежат в основном потоке.

procedure TDM.IdTCPServer1Execute(AContext: TIdContext);
begin
...
SSize := AContext.Connection.IOHandler.ReadInteger;
AContext.Connection.IOHandler.ReadStream(idStrm, SSize);

tb.LoadFromStreamViaFormat(Strm, GS.BSF_Data);
Запись таблицы(метод основного потока)
...
Дисконнект
end;

Есессено Запись таблицы не работает, подскажите как синхронизировать потоки?


 
Lilu   (2006-10-17 12:09) [10]

Сергей М. :))))  я понимаю и там и там(9,10) создаются потоки для каждого соединения, возможно даже к ним можно обратиться, но как?


 
umbra ©   (2006-10-17 12:10) [11]

да, чего-то я загнался. :) Обработчик сервера уже выполняется в контексте потока. к нему не надо обращаться, Вы уже в нем.


 
Сергей М. ©   (2006-10-17 12:12) [12]


> Есессено Запись таблицы не работает


Это почему же "есессно" ?


 
Lilu   (2006-10-17 12:15) [13]


> да, чего-то я загнался. :) Обработчик сервера уже выполняется
> в контексте потока. к нему не надо обращаться, Вы уже в
> нем

Круто! я в нем,  только как мне вызывать метод основного потока?


 
Lilu   (2006-10-17 12:19) [14]


> > Есессено Запись таблицы не работает
>
>
> Это почему же "есессно" ?

потому как с этой таблицей (в которую я собираюсь загнать данные) работает основной поток


 
Сергей М. ©   (2006-10-17 12:21) [15]

Что мешает доп.потоку создать свои собственные объекты доступа к объектам БД ?


 
Сергей М. ©   (2006-10-17 12:24) [16]

В OnConnect:

- создать IBDataBase, IBTransaction, IBDataSet/IBQuery/IBTable, связать и настроить их как положено

В OnExecute обращаться к своим компонентам доступа, а не к компонентам доступа, используемым осн.потоком


 
Lilu   (2006-10-17 12:29) [17]


> Что мешает доп.потоку создать свои собственные объекты доступа
> к объектам БД ?

ничего не мешает :) только это не в этом цель поставленой задачи.
метод основного потока, реализует нехилый алгоритм,- работает со всевозможными СУБД и реализовать его работу в другом потоке возможно но неправильно.


 
umbra ©   (2006-10-17 12:41) [18]

Нашел! Собственно поток представляет св-во TIdContext.Yarn


 
Сергей М. ©   (2006-10-17 12:43) [19]


> метод основного потока


Давай быть точнее - у потоков как у ОС-объектов нет никаких "методов".


> реализовать его работу в другом потоке возможно но неправильно


И почему же ? Аргументируй ...

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


 
Сергей М. ©   (2006-10-17 12:46) [20]


> umbra ©   (17.10.06 12:41) [18]


Если у этого самого Yarn как наследника TThread метод syncronize не обубликован, то ситуация ничем не отличается от изложенной в [3]


 
umbra ©   (2006-10-17 13:42) [21]

Сергей М. ©   (17.10.06 12:46) [20]

опубликован.


 
Сергей М. ©   (2006-10-17 13:49) [22]


> umbra ©   (17.10.06 13:42) [21]


Тады умываю руки.


 
Lilu   (2006-10-17 14:15) [23]

в общем  Yarn в моей Indy наследник TObject причем никаких новых ни свойст ни методов
type
 TIdYarn = class(TObject)
 protected
 public
 end;
:( и syncronize у него не наблюдается.
Нашла IdTCPServer1.Contexts - список потоков, мож через него что нить можно сделать?!
Пока сделала через CriticalSection. Пока все работает.
Но с синхронизацией хотелось бы разобраса.


 
Сергей М. ©   (2006-10-17 14:19) [24]


> Пока сделала через CriticalSection


Тебя поджидает засада.


> > реализовать его работу в другом потоке возможно но неправильно


Жду ответа на свой вопрос - почему "неправильно" ...

По поводу же синхр.сообщений окну осн.потока как варианту синхронизации - рекомендация (как разумная альтернатива для Win) остается в силе


 
umbra ©   (2006-10-17 15:19) [25]


>  Yarn в моей Indy наследник TObject причем никаких новых
> ни свойст ни методов

Экземпляром какого именно объекта будет Yarn в рантайме зависит от того, что использует сервер - потоки или нити. По умолчанию это потоки и Yarn будет экземпляром TIdThread. Так что см. справку для TIdThread


 
umbra ©   (2006-10-17 15:20) [26]


>  Yarn в моей Indy наследник TObject причем никаких новых
> ни свойст ни методов

Экземпляром какого именно класса будет Yarn в рантайме зависит от того, что использует сервер - потоки или нити. По умолчанию это потоки и Yarn будет экземпляром TIdThread. Так что см. справку для TIdThread


 
Сергей М. ©   (2006-10-17 15:29) [27]


> umbra ©   (17.10.06 15:19) [25]



> потоки или нити


Э-э-э ...

М.б. таки будет правильней "нити или волокна" ?


 
umbra ©   (2006-10-17 15:51) [28]

2 Сергей М. ©   (17.10.06 15:29) [27]

для себя я всегда перевожу thread как поток, а fiber как нить. Привычка, однако :)


 
Ketmar ©   (2006-10-17 15:57) [29]

>[28] umbra(c) 17-Oct-2006, 15:51
поймать бы того гада, который thread в первый раз "потоком" обозвал... %-)


 
Сергей М. ©   (2006-10-17 16:15) [30]


> umbra ©   (17.10.06 15:51) [28]


С привычкой бороться сложно и глупо.
И все же файбер - это волокно, т.е. составляющая нити, а не собственно нить.


 
Anatoly Podgoretsky ©   (2006-10-17 21:30) [31]


> поймать бы того гада, который thread в первый раз "потоком"
> обозвал... %-)

Поздно пить шампанское.


 
Lilu   (2006-10-18 05:15) [32]


> Жду ответа на свой вопрос - почему "неправильно" ...

может я что-то непонимаю... предположим для выполнения процедуры1 в основном потоке я использую IBTable, OraTable, ZTable и еще кучу других компонент(может порекомендуете ADO, но настройки ... ) и создавать эти компоненты в потоке соединения повторно + копировать код процедуры1 не по программистски.


 
Сергей М. ©   (2006-10-18 08:37) [33]


> создавать эти компоненты в потоке соединения повторно ..не по программистски.


Еще как "по-программистски" !


> копировать код процедуры1 не по программистски


А вот это действительно "не по-программистски".

По-программистски же будет создать отдельную ф-цию, реализующую тот самый "нехилый алгоритм" и принимающую параметрами конкретные экз-ры компонентов доступа к БД, с которыми этот "нехилый алгоритм" и будет работать при вызове ф-ции. Каждый поток, заинтересованный в выполнении этого алгоритма, создает свой собственный набор объектов доступа к БД и вызывает ту самую функцию со своими объектами-параметрами.


 
Lilu   (2006-10-18 08:59) [34]


>cоздать отдельную ф-цию

отдельную от чего?

> собственный набор объектов доступа к БД и вызывает ту самую
> функцию со своими объектами-параметрами

то есть потоки синхронизировать не нужно.


 
Сергей М. ©   (2006-10-18 09:18) [35]


> отдельную от чего?


Отдельную от всего)

Просто некую ф-цию. например:

function DoSomeThingWithDatabase(DB: TIBDatabase; TA: TIBTransaction): SomeResult;
begin
..
end;


> то есть потоки синхронизировать не нужно


Конечно не нужно !


 
Lilu   (2006-10-18 17:50) [36]

так не работает


 
Сергей М. ©   (2006-10-19 08:07) [37]

значит у тебя ошибка в программе


 
umbra ©   (2006-10-19 10:41) [38]

см. umbra ©   (17.10.06 15:20) [26]



Страницы: 1 вся ветка

Текущий архив: 2007.04.01;
Скачать: CL | DM;

Наверх




Память: 0.56 MB
Время: 0.03 c
11-1150844501
parovoZZ
2006-06-21 03:01
2007.04.01
Бросил на GRushPanel KolLabel...


15-1173161727
Alkid
2007-03-06 09:15
2007.04.01
Кратифф на тему названий техники (не мой)


2-1173097926
M1sT
2007-03-05 15:32
2007.04.01
Поиск в базе и создание отчета по результатам поиска...


2-1173293266
Ezorcist
2007-03-07 21:47
2007.04.01
вывести текст на image сожержащий jpeg?


2-1173773084
mr.ASH
2007-03-13 11:04
2007.04.01
Выделение блоков памяти