![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Прощу помощи разобраться со службой. [D7, XP, 2003]
Lamer6666 © (2012-06-17 09:23:00)Доброго времени суток уважаемы.
Начал осваивать службы на основе VCL (WinAPI пока сложновато.)
Прочитал статью на королевстве о создании служб (события, методы) но в целом представление не сложилось.
1. Создал ServiceAplication
2. Скомпилировал
3. service1.exe /install служба появилась в остановленном виде.
Далее как я понимаю необходимо использовать OnStart. Согласно статье тут нужно запускать потоки.
Можно нечто блок схемы функционирования сервиса и поток в нем привести?
Например я понимаю так, исходя из моей задачи:
С разделе OnStart запускаю таймер (пока не представляю как), и по таймеру выполняю например чтение строки из файла 1.txt и запись ее в 2.txt. Так мой сервис работает целый день. Что указать по событию onStop?
Прошу прощение за мое не понимание, и возможно не правильную формулировку, прошу помощи!
Lamer6666 (2012-06-19 12:26:00) [21]В принципе я так и планирую что таймер в основном потоке вертеться будет, опрашивать БД/ФАЙЛ
Если появились новые записи то что то в роде:
NewThread1:=TThread.Create(true);
NewThread1.FreeOnTerminate:=true;
NewThread1.Priority:=tpLowest;
NewThread1.Resume;
в NewThread1 буду выполнять отправку методом GET.
или не верное мыслю?
Сергей М. (2012-06-19 11:30:00) [22]
> На TService кинул таймер
И события таймера у тебя при этом обрабатываются в осн.потоке.
А вот если ты создашь (и уничтожишь потом соотв-но) таймер в OnExecute, то работать он будет именно в доп.потоке.
Остается организовать цикл диспетчеризации сервисных и таймерных сообщений.
Lamer6666 (2012-06-19 10:12:00) [23]Да я ничего не думаю, нигде нет толковых примеров (как слепой тыкаюсь туда сюда), в итоге как смог так и написал, поэтому прошу подсказки что именно переделать необходимо?
Мой пример работает и начинает запись по таймеру после запуска службы.
Так что не верное реализовано, что надо переделать??
sniknik (2012-06-19 09:36:00) [24]> Ну я не про файлы, а про реализацию службы. ))
в показанном нет НИЧЕГО от реализации службы. - все случайные совпадения, имена и события вымышлены... или как то так.
вот реально думаешь, что елинственное имя функции ServiceStart, это реализация???
Lamer6666 (2012-06-19 09:01:00) [25]
> Работа с файлами через файловые переменные — прошлый век.
Ну я не про файлы, а про реализацию службы. ))
Давайте будем жрать! (2012-06-19 07:43:00) [26]
> хотелось бы услышать ваше мнение
Работа с файлами через файловые переменные — прошлый век.
Lamer6666 (2012-06-18 22:51:00) [27]Я реализовал следующим образом:
1. На TService кинул таймер
2.
procedure TService1.ServiceStart(Sender: TService; var Started: Boolean);
begin
AfterInstall(Sender);
end;
3. Создаю/проверяю файлик к который буду писать текст
procedure TService1.ServiceAfterInstall(Sender: TService);
var
path: string;
begin
Path:= ExtractFilePath(Application.ExeName) + 'File.txt';
AssignFile(F,Path);
if FileExists(path) then
Append(f)
else
Rewrite(f);
end;
4. Осуществляю запись:
procedure TService1.Timer1Timer(Sender: TObject);
begin
Writeln(f,DateTimeToStr(Now)+': Проверка на запись.');
end;
сильно не ругайте, так как код пробный... хотелось бы услышать ваше мнение.
Сергей М. (2012-06-18 22:40:00) [28]
> Lamer6666 (18.06.12 21:44) [24]
Все это расчудесно делается прямо в обработчике OnExecute, который исполняется в доп.потоке.
DVM (2012-06-18 22:07:00) [29]Я бы всю полезную работу сервиса делал в отдельном потоке. Так и универсальнее, в случае чего можно программу и в консольное приложение превратить (можно даже комбинированное) и в демон (под никс) и вероятность воздействия на работу службы минимальна. Причем запускать/останавливать свои потоки надо именно в OnStart OnStop событиях сервиса именно там сервис умеет обрабатывать длительный старт или длительную остановку, что позволяет оставаться не прибитым. В OnExecute можно оставить минимум кода.
Lamer6666 (2012-06-18 21:44:00) [30]Основной поток производит чтение из БД или ФАЙЛА данных каждые 5 секунд. Если есть новые записи в БД или ФАЙЛЕ то создает доп. поток отправляющий эти новые данные методом GET на сторонний сервер.
Т.е. взял данные отправил в доп. поток, прошло 5 сек взял данные отправил в доп. поток и т.д. таки образом основной поток не ждет пока выполниться GET (ведь он может не уместиться в интервал таймера)
Ну и плюс буду контролировать количество созданных потоков.
Разве не верный подход?
Сергей М. (2012-06-18 20:15:00) [31]
> запросы хочу оформлять в доп. потоке, а основной поток уже
> избавлен от подобных операций
Интересно, и чем же таким архиполезным занят основной поток твоего сервис-приложения ?
sniknik (2012-06-17 20:14:00) [32]> Не могли бы вы дать ссылку на простенький пример реализации службы на основе событий OnStart/OnStop?
вопрос, где бы ее взять ссылку то? чтобы дать тебе... дай ка догадаюсь, предлагаешь поискать за тебя????
+ на "основе событий" звучит как идиотизм... нет такого, просто в ссылке было описано 2 модели, примерных, как можно сделать. но вообще без разницы, где вызывать поток если он нужен... с тем же успехом его можно начать в execute.
это к тому, если искать в гугле то просто пример службы, если добавить "на основе событий OnStart/OnStop" то скорее всего ничего не найдешь.
Lamer6666 (2012-06-17 19:49:00) [33]
> + если есть сомнение в том, что операция не вложится в таймаут
> то лучше делать дополнительный рабочий поток.
Вот поэтому я и склонялся больше в сторону реализации на основе событий OnStart/OnStop где все GET запросы хочу оформлять в доп. потоке, а основной поток уже избавлен от подобных операций.
Не могли бы вы дать ссылку на простенький пример реализации службы на основе событий OnStart/OnStop? Что бы можно было наглядно разобраться что к чему?!
Заранее премного благодарен.
sniknik (2012-06-17 19:34:00) [34]в показанном варианте совсем не корректно, даже без GET.
> в цикле тогда должна быть обработка (диспетчеризация) событий...
+ если есть сомнение в том, что операция не вложится в таймаут то лучше делать дополнительный рабочий поток.
Lamer6666 (2012-06-17 19:20:00) [35]Огромное спасибо sniknik и всем другим ответившим мне, еще раз перечитал статью, наверное стоит начать работу с события OnExecute как было предложено выше:
while not Terminated do begin
ReadLn(F1, S);
Try
Тут отправка данных методом GET
Finally
ReportStatus
End;
Sleep(X);
end;
но насколько корректно будет вести себя с служба при длительном GET?
sniknik (2012-06-17 15:10:00) [36]> правильно ли я понимаю?
неправильно.
метод старт в потоке сервиса предназначен для проверки возможности работы и ответа диспетчеру служб об этом. протормозишь не запустит по таймауту.
закрытие для такого же правильного завершения с оповещением.
вся работа/циклы, как и в простом потоке ведется в execute. в цикле тогда должна быть обработка (диспетчеризация) событий... т.к. одно из событий это запрос "ты жив?" от диспетчера служб... протормозишь значит висит, будут "санкции".
в ссылке про такую модель написано, и там же про вторую (или наоборот первую, чисто пролистал).
- запустить свой поток в старте (без тормозов, помнишь? поэтому поток, а не какие то действия) и вся работа уже в нем. execute тогда не назначается, и используется дефаултный в предке, где кроме цикла с диспетчером событий ничего нет.
Lamer6666 (2012-06-17 14:17:00) [37]Огромное спасибо sniknik
Картина проясняется понемногу, в целом понял реализацию свое задачи так:
1. Запускаю сервис
2. В по старту начинаю проверять файл или таблицу в БД
3. Если есть новые записи, то создаю доп.поток который методом GET отправляет запрос.
и так по циклу, правильно ли я понимаю?
только не понятно все же как создать цикличную проверку БД или файла в сервисе по старту?
sniknik (2012-06-17 13:18:00) [38]> раз надо что то выполнять через определенные промежутки времени, то для этого есть TTimer.
> К тому же TTimer не "подвешивает" исполнение когда и приложение как sleep.
sleep не подвешивает, он отдает управление другим потокам, если ты его в основном "зарядишь" то будет вид что висит...
но дополнительные для того и делают, чтобы они работали параллельно основному... ну и что что доп поток подождет чуток? на основной это влиять не должно (если написано правильно) и никаких зависаний не будет.
а сервис по сути это просто поток... присмотрись внимательнее на методы. другое дело он взаимодействует с диспетчером служб... отвечает на запросы типа "ты еще жив?" и если занять надолго, и не ответить...
sniknik (2012-06-17 13:09:00) [39]> как сказано тут
не совсем корректно сказано, ИМХО, тем более вырванное из контекста, можно подумать что функции предлагают пихать в цикл потока, когда на самом деле там речь о "диспетчеризации" событий, отсутствующих в потоке, без самостоятельного написания.
Lamer6666 (2012-06-17 11:38:00) [40]
> и зачем здесь таймер?
> потому что надо "раз в минуту", а на нем часики нарисованы?
>
Прошу прощения, видимо это стереотипы программирования раз надо что то выполнять через определенные промежутки времени, то для этого есть TTimer. К тому же TTimer не "подвешивает" исполнение когда и приложение как sleep.
Одно дело система приложение работает и считает таймером а другое дело она просто спит, мне кажеться это не совсем верно.
Может наверное я что то и не понимаю.