Многопоточность в CGI

← →
phantom © (2007-12-13 11:28) [0]

Подскажите в чем разница между программированием нескольких потоков в CGI и в формах. Я написал код в форме в котором несколько потоков обращаются к объектам TTable и это все работает, но когда я этот код переношу в CGI. Поток при попытке обратится к TTable получает ошибку что объекта по данному адресу нет. Заранее спасибо.

← →
Сергей М. © (2007-12-13 11:37) [1]

Показывай код

← →
Сергей М. © (2007-12-13 11:37) [2]

И причем здесь Сети - тоже поясни ..

← →
phantom © (2007-12-13 12:07) [3]

Ну вопрос отношу к людям которые пишут для интернета. Может сталкивались с таким.
Я честно говоря сомневаюсь что мне ответят в других ветках.
А код простой
так вызываю поток
Arh:=ThreadRab.Create(false);

вот тело потока

procedure ThreadRab.execute;
begin
WaitForSingleObject(hMutex1,INFINITE);
with WebModule1 do
begin
Hal1.Close; // А тута уже ошибка
Hal1.DatabaseName:="d:\dbf";
Hal1.TableName:="a_f434t.dbf";
Hal1.Open;
Hal1.MemoryIndexAdd("wer1","nomer+data_doc","nomer="1817"",Duplicates,Ascending);
end;
ReleaseMutex(hMutex1);
end;

← →
Palladin © (2007-12-13 12:16) [4]

дело в том что объекта WbModule1 не существует во время выполнения CGI
и не важно сколько там потоков

прикол довольно старый...

← →
Сергей М. © (2007-12-13 12:23) [5]

Речь идет о standalone-приложении или о библиотеке ?
Поясни, зачем вообще нужна многопоточность ..

В какой момент создается объект, на который ссылается WebModule1 ?

← →
Palladin © (2007-12-13 12:29) [6]

> Сергей М. © (13.12.07 12:23) [5]

а не важно, глобальная ссылка

Var
WebModule1:TWebModule1

равна Nil

нужно искать другие пути, либо создавать TTable в RT, либо на TWebModule1.OnCreate сохранять Self вручную...

← →
Сергей М. © (2007-12-13 12:35) [7]

> Palladin © (13.12.07 12:29) [6]

> не важно, глобальная ссылка

С чего ты взял ?
Это только если заготовка проекта была сделана по станд.шаблону эксперта и не претерпела после этого изменений в части переноса ид-ра WebModule1 из раздела ид-ров глоб.переменных куда-либо еще

← →
Palladin © (2007-12-13 12:40) [8]

> Сергей М. © (13.12.07 12:35) [7]

опыт, старый опыт :)

проверь :) да и зачем, вот кусок

procedure TWebApplication.CreateForm(InstanceClass: TComponentClass; var Reference); begin // Support CreateForm for backward compatability with D3, D4, and // D5 web modules. D6 generated web modules register a factory. if WebModuleClass = nil then WebModuleClass := InstanceClass else if WebModuleClass <> InstanceClass then raise Exception.CreateRes(@sOnlyOneDataModuleAllowed); end;

← →
phantom © (2007-12-13 14:32) [9]

Спасибо огромное за разъяснение. Несколько потоков хочу сделать тк сервер многопроцессорный, а поток должен проиндексировать табличку и по моему мнению так будет быстрее.
TTable решил делать в RT , но я так понял если добавить в проект DataModule то можно и так сделать .

← →
Сергей М. © (2007-12-13 14:49) [10]

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

В смысле дополднительный ?
А основной все это время чем будет занят ?

← →
phantom © (2007-12-13 15:15) [11]

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

← →
Сергей М. © (2007-12-13 15:27) [12]

> По логике вещей должнобыть в полтора раза быстрее чем все
> последовательно делать

Нет, не должно.

← →
Anatoly Podgoretsky © (2007-12-13 15:32) [13]

> phantom (13.12.2007 15:15:11) [11]

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

← →
KSergey © (2007-12-13 15:47) [14]

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

Скорее тогда уж стоит устроить некий back-ground процесс, который будет эти индексы перестраивать периодически.
А то ка кринутся 10 (всего лишь) одновременных клиентов к такому скрипту - и все умрет на ожидании перестроения индексов, что, как было сказано - есть операция монопольная.

← →
Palladin © (2007-12-13 15:52) [15]

> нет смысла CGI и проч. WEB-приложения громоздить многопоточынми

смысл-то как раз есть, но не в данном случае

← →
Anatoly Podgoretsky © (2007-12-13 15:54) [16]

> Palladin (13.12.2007 15:52:15) [15]

Смысла нет, если только инструмент не умеет работать ассинхронно.

← →
Palladin © (2007-12-13 16:09) [17]

> Anatoly Podgoretsky © (13.12.07 15:54) [16]

причем тут инструмент? смысл есть. привожу пример. разрабатывали мы КИС для администрации МО МС. баз туева хуча, всяких разных, информацию местами собирать нужно из нескольких, у многих отделов разное ПО, где то на клиппере, где то на оракле, где то в DBF, где то вообще... экзотические решения ( "парус" или "флиппер" например :) )... и тд... время отклика тоже разное... бо сам понимаешь... откуда у администрации деньги на высокропроизводительные машины... соответственно самое оптимальное решение данные брать по потокам...

Доступ как ни странно не монопольный, индекс создается в памяти для каждой CGI свой. четырех процессорный сервер с RAID справляется с поставленой задачей. Процесс действительно быстрее (смотел по загрузке).
Сначала тоже хотел крутить фоновый сервис на сервере чтоб все строил зарание , Это новерно в даной ситуации самый лучьший вариант.

> phantom © (13.12.07 16:35) [18]

что ж ты молчал про 4хэ-процессорность... :) никто бы не выступал что про многопоточность CGI :)

> Palladin © (13.12.07 16:09) [17]

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

> Anatoly Podgoretsky © (13.12.07 16:52) [20]

что ждать?
заявление было обобщенное, потокам в CGI не место... отвечено было:место и очень часто...

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

да и дело не только в базах, на них внимание заострять не стоит. например см. [18]

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

> Palladin (13.12.2007 17:10:21) [21]

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

> Anatoly Podgoretsky (13.12.2007 18:35:22) [22]

Добавление - при условии, что есть более одного длительного запроса. При одном длительном запросе нужды в потоке нет, само CGI приложение или расширение и так в отдельном потоке.

> Anatoly Podgoretsky © (13.12.07 18:51) [23]

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

Многопоточность в CGI Найти похожие ветки