Запрос в потоке. Правильно пишу?

← →
Ega23 © (2010-12-01 10:51) [40]

> И убиваю поток, когда пользователь новый запрос просит выполнить

Зачем? Ставь его в Suspend. Соединение создано, НД создан.

← →
12 © (2010-12-01 11:02) [41]

> Screen.Cursor := crSQLWait;
> try
> DataSet.Open;
> finally
> Screen.Cursor := crDefault;
> ebd;

так и было до потока
но тогда пользователь в другое МДИ окно не мог переключится и поредактировать что-то, пока запрос идет.

← →
Ega23 © (2010-12-01 11:04) [42]

А, ну это другое дело.

← →
12 © (2010-12-01 11:05) [43]

> ачем? Ставь его в Suspend. Соединение создано, НД создан.

Логично, ща..

← →
Ega23 © (2010-12-01 11:19) [44]

На самом деле я бы пул соединений сделал. Т.е. есть класс потока, есть класс - список этих потоков. У класса-списка есть свойство, типа MaxConnections. Также этот класс-список знает, какие потоки у него в данный момент раюотают, а какие - простаивают.
Передал туда текст запроса, он пробежался по списку. если нашёл свободный - передал запрос ему. Если свободных не нашёл - создал новый (если Count < MaxConnections). Если свободных нет и Count = MaxConnections - ждём, пока кто-то освободится.

← →
12 © (2010-12-01 11:23) [45]

> Ega23 © (01.12.10 11:19) [44]

Больно сурьезно
если будет надобность - надо будет попробавать нечто подобное сделать

← →
Игорь Шевченко © (2010-12-01 11:26) [46]

> но тогда пользователь в другое МДИ окно не мог переключится
> и поредактировать что-то, пока запрос идет.

Вот это и есть САМОЕ ГЛАВНОЕ ЗАБЛУЖДЕНИЕ.

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

← →
Ega23 © (2010-12-01 11:27) [47]

> Больно сурьезно

В целом именно так и делается. Таким образом можешь самостоятельно нагрузкой на БД рулить.

← →
Ega23 © (2010-12-01 11:28) [48]

> Вот это и есть САМОЕ ГЛАВНОЕ ЗАБЛУЖДЕНИЕ.

ИМХО, +1.
Юзер скорее на "Косынку" какую-нибудь переключится.

← →
Anatoly Podgoretsky © (2010-12-01 13:34) [49]

> 12 © (01.12.10 10:40) [38]

Анимация

← →
Anatoly Podgoretsky © (2010-12-01 13:35) [50]

> 12 (01.12.2010 10:40:38) [38]

Ассинхронные запросы. Но надо уметь с ними работать. Ассинхронность, веэде,
не всем подвластна.

← →
Anatoly Podgoretsky © (2010-12-01 13:37) [51]

> Юзер скорее на "Косынку" какую-нибудь переключится.

Боятся. Предпочитают подождать.

← →
MsGuns © (2010-12-01 20:46) [52]

>Ega23 © (01.12.10 11:28) [48]
>Юзер скорее на "Косынку" какую-нибудь переключится.

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

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

← →
Leonid Troyanovsky © (2010-12-01 22:42) [53]

> MsGuns © (01.12.10 20:46) [52]

> а многопоточность весьма уместна и реально в разы повышает
> эффективность работы с прогой.

Повышение эффективности многопоточности можно связать,
например, с ростом количества процессоров в системе, хотя,
уж вовсе не в разы.

--
Regards, LVT.

← →
Ega23 © (2010-12-01 23:42) [54]

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

Открыл m-Torrent и Thunderbird. Посмотрел на интерфейс. MDI не увидел.
Что я делаю не так?

← →
MsGuns © (2010-12-02 11:22) [55]

А кто говорил про МДИ ?

← →
MsGuns © (2010-12-02 11:25) [56]

>Leonid Troyanovsky © (01.12.10 22:42) [53]
>Повышение эффективности многопоточности можно связать,
>например, с ростом количества процессоров в системе, хотя,
>уж вовсе не в разы.

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

← →
Ega23 © (2010-12-02 11:55) [57]

> А кто говорил про МДИ ?

Влад говорил.

> Проверено многократно.

С этим никто не спорит. "Всякому овощу...", как ИШ любит говорить.
Вот только всё равно в [32] пункты 4 и 5 - чушь. :)

← →
Игорь Шевченко © (2010-12-02 16:32) [58]

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

"Вы, сударь, ерунду говорите. И хуже всего то, что говорите безапеляционно и уверенно"

← →
MsGuns © (2010-12-02 18:46) [59]

>Ega23 © (02.12.10 11:55) [57]
>Вот только всё равно в [32] пункты 4 и 5 - чушь. :)

>Игорь Шевченко © (02.12.10 16:32) [58]
>"Вы, сударь, ерунду говорите. И хуже всего то, что говорите >безапеляционно и уверенно"

Аргументы, как всегда, убойные.
Уполз в кусты помирать :)

← →
Ega23 © (2010-12-02 19:21) [60]

> Аргументы, как всегда, убойные.

Вы хочите песен?
Их есть у меня

4. Если результаты "фонового" запроса должны отображаться, то сам запрос (TXXXQuery) должен быть создан в основном потоке, а выполняться во вторичном, куда собственно и следует передавать указатель на квери при создании и запуске потока. Это позволит потоку благополучно помереть после завершения, а результатам - остаться для дальнейшего использования

Кто сказал, что "сам TXXXQuery должен быть создан" ...
Что вообще такое класс TThread, тебе известно? Как запустить код на исполнение в отдельном треде без данного класса? Кто там, где и когда помирает?
Есть мнение, что ты не очень разбираешься в этой кухне, ничего личного.

5. Критические секции нужны лишь на создание объектов, но никак ни на сам ход выполнения запроса - для этого всего лишь нужно получать и обрабатывать сообщения сервера в "обычном", некритичном коде. Что легко делвется в "управляемом" запросе.

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

З.Ы. рекомендую внимательно посмотреть на код TThread.

← →
MsGuns © (2010-12-02 19:50) [61]

>Ega23 © (02.12.10 19:21) [60]

Мухи и котлеты :)
Если тебе нравится считать, что я не разбираюсь, то на здоровье :)

← →
Ega23 © (2010-12-03 11:33) [62]

> Если тебе нравится считать, что я не разбираюсь, то на здоровье

Серёж, мы же не первый год на форуме. Да и не нубы, вроде как. И "за базар" отвечать должны тоже не так, как нубы.
Так что давай, аргументируй. Почему "TxxxQuery надо создавать в главном потоке" и почему "крит.секция нужна только на момент создания объекта".
Как говорится, TITS or GTFO

← →
Юрий Зотов © (2010-12-04 23:20) [63]

> Ega23 © (03.12.10 11:33) [62]

> Почему "TxxxQuery надо создавать в главном потоке"

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

← →
MsGuns © (2010-12-05 15:21) [64]

>Ega23 © (03.12.10 11:33) [62]
>Серёж, мы же не первый год на форуме. Да и не нубы, вроде как.

Не нубы, но иногда хамим :)

>И "за базар" отвечать должны тоже не так, как нубы.
>Почему "TxxxQuery надо создавать в главном потоке"

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

>и почему "крит.секция нужна только на момент создания объекта".

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

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

← →
Ega23 © (2010-12-05 17:19) [65]

> Создавать его, конечно, можно где угодно, но логично поручить
> это главному потоку.

Ганс писал:
Если результаты "фонового" запроса должны отображаться, то сам запрос (TXXXQuery) должен быть создан в основном потоке, а выполняться во вторичном, куда собственно и следует передавать указатель на квери при создании и запуске потока.

Собственно, я и доковырялся до должен. Ибо он может быть создан где угодно.

← →
Ega23 © (2010-12-05 17:24) [66]

> Если квери создать в самом потоке, то по завершении запроса
> нужно либо куда-то в осн.поток эти данные передать (скопировать),
> либо не убивать поток до тех пор, пока данные запроса не
> станут ненужными.

Дааааа?
Объясни мне, что мешает создать кверь в дополнительном треде, выполнить, передать на неё указатель основному треду, после чего убить дополнительный тред?

> Для его создания критическая секция нужна, ясен красень.

Зачем она нужна??? Да ещё и на создание? Для чего????

Are binary programmers deathless?...
:o)

>Ega23 © (05.12.10 17:24) [66]
>Объясни мне, что мешает создать кверь в дополнительном треде, >выполнить, передать на неё указатель основному треду, после чего убить >дополнительный тред?

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

>> Для его создания критическая секция нужна, ясен красень.
>Зачем она нужна??? Да ещё и на создание? Для чего????

Для того же, для чего нужны критические секции для любого кода, в котором могут быть независимые от программы ошибки. Например, при выделении ресурсов системой. Опять же делаю как завещали умные люди :)

ЗЫ. Похоже, ты, Олежа, просто уперся и не хочешь отступать. Поэтому спор дальнейший бессмысленен. На что я и намекал в [61] ;)

> Т.е. если кверик был создан в нити, то нить и должна его
> прибить погибая.

У тебя каша в голове. Читай внимательно MSDN по CreateThread
Если ты мне там хоть один класс покажешь - я прилюдно буду извиняться.

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

Один тред - один коннект. Иначе грабли, рано или поздно.

> Для того же, для чего нужны критические секции для любого
> кода, в котором могут быть независимые от программы ошибки.
> Например, при выделении ресурсов системой. Опять же делаю
> как завещали умные люди :)

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

> ЗЫ. Похоже, ты, Олежа, просто уперся и не хочешь отступать.
> Поэтому спор дальнейший бессмысленен.

Да если бы это в потрепаловке было, или там в базах - я бы давно слюной плюнул на дремучесть, да и дело с концом. ССЗБ, можешь писать как вздумается.
Но в начинающих хрень постить - это некузяво.

>Ega23 © (06.12.10 11:08) [69]
>У тебя каша в голове. Читай внимательно MSDN по CreateThread

Разберись сначала со своей

>Один тред - один коннект. Иначе грабли, рано или поздно.

А вот это чушь полная

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

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

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

Не даем себе труд хотя бы элементарно въехать в смысл того, что говорят, зато продолжаем хамить ? На здоровье, но без меня.

> Крит.секция = объект синхронизации ?

А что это, по-твоему?

> И причем здесь вообще синхронизация - я про нее хоть заикнулся?

Дык и я о том же, синхронизация не нужна, однако "крит.секция нужна, ясен пень". Может таки RTFM пора?

> Не даем себе труд хотя бы элементарно въехать в смысл того,
> что говорят

Искренне пытаюсь уже несколько дней это сделать. Почему создавать кверь я должен в основном потоке, почему я должен использовать одно соединение, а также нафига нужна крит.секция в вышестоящем примере - я так и не понял.

> На здоровье, но без меня.

Понятно. Т.е. слив засчитан, да?

← →
han_malign (2010-12-06 18:21) [73]

> (TXXXQuery) должен быть создан в основном потоке, а выполняться во вторичном

- если это OLE провайдер, и интерфейс создается в STA(по умолчанию, см. comobj), то доп. поток не поможет - один фиг все будет маршалироваться в контекст основного потока... Другое дело, что большинство провайдеров и так асинхронные и вынос явного ожидания завершения запроса в другой поток - это просто чесание левого уха правой пяткой...

> то доп. поток не поможет - один фиг все будет маршалироваться
> в контекст основного потока...

CoInitialize ?

← →
Вариант (2010-12-07 06:58) [75]

> Ega23 © (06.12.10 19:58) [74]

> CoInitialize ?

Кстати тема интересная. Я не уверен в своем правильном понимании этой темы. Поэтому разовью, а кто хорошо знает пусть поправит. Создав COM объект в потоке имеющий апартамент STA (в дельфи основной поток по умолчанию) мы вызывая методы объекта объекта даже в другом потоке, все равно переадресуем вызов этих методов (маршалируем) в поток создавший этот объект. То есть имеем ситуацию
> han_malign (06.12.10 18:21) [73]
И Coinitialize в другом потоке (создаем апартамент STA для вызвавшего потока) не поможет, если COM объект был создан в другом. Ибо методы его в тихую будут вызваны в создавшем его потоке.....

> Ибо методы его в тихую будут вызваны в создавшем его потоке.
> ....

Это уже интересно. Ща обдумаем.

← →
han_malign (2010-12-07 12:57) [77]

> CoInitialize ?

- CoInitializeEx(nil,COINIT_MULTITHREADED)

> Ибо методы его в тихую будут вызваны в создавшем его потоке.....

- все чуть запутанней: http://www.compdoc.ru/prog/cpp/com/ch5/ch52.shtml

Запрос в потоке. Правильно пишу? Найти похожие ветки