Такая проблема - есть процедура, написанная на фокс про, служит для синхронизации бд одной организации по фтп, между офисами. Процедура работает довольно нестабильно, и время от времени вешается, даже не то, что вешается - очень сильно задумывается, это может длится пару часов. Синхронизация должна идти каждые минут 10. Т.е. процедура работает в бесконечном цикле, каждые 10 минут синхронизируя бд. Само подвисание особо не мешает, если процесс грохнуть и потом запустить вручную, все идет нормально, некоторый промежуток времени, пока опять не "задумается".
Не всегда получается вовремя заметить подвисание и перезапустить, может пройти значительный интервал времени.
Вариант решения - написать внешнюю программку, которая подвисания будет отлавливать и процесс перезапускать.
Как думаю диагностировать подвисание - в начале синхронизации создавать некий файлик, дата модификации которого будет менятся при каждой синхронизации (допишу этот момент в фоксе).
Внешняя программа будет смотреть время модификации, если оно >10 минут - процесс грохать и запускать заново.
Писать планируется в СиБилдере, ибо это единственное, с чем как-то знаком 
Собственно вопрос - как это реализовать программно? Как убить нужный процесс и перезапустить его? Насколько я понимаю, надо исползовать функции WinAPI, мне же с ними работать не приходилось. Надо сделать, чтоб процесс постоянно висел в фоне, еще у него не должно быть главной формы. Как это сделать?
Буду признателен за любые идеи, касательно реализации программы. 
Если можно - расписывайте, пожалуйста, ваши идеи, я в этом новичек 

вариант ведения лога учета времени мб и хорош, но это "целый файл!"...
как я когда-то делал :

Итак, имеем сервис NT который будет осуществлять синхронизацию (репликацию -- фокс сам не умеет?).
Он содержит два потока : 1)следящий 2)подвисающий
1 следит за 2.
Как следить: 
можно банально : на старте потока 2 устаналивается Event что потоко начал работу. 1-ый в беск. цикле "смотрит" этот event. Как только Event "встал" 1-ый поток "замерзает" на 10 минут (средставми все того же WaitForSingleObject). Если по окончании "заморозки" Event все еще стоит - то происходит убивание потока 2 (принудилово TerminateThread) и его (2-ого потока) перезапуск. Чтобы убивания не происходило - второй поток по окончании работы Сбрасывает Event.

Можно не банально : делать два процесса - один следит за другим 8-)
Еще не банальнее (со "стильным статусом") : процесс (поток -- тут не важно) уведомляет перед преступлением к работе о количестве данных подлежащих репликации (удобно ввести статусное поле - реплицировано\нет aka status) (select count(*) from tab where status!=ST_REPLICATED). Второй посылает уведомления (например оконные сообщения средставами PostMEssage об обработки одной записи (или одного блока записей). Т.о. имеем даже прогресс-бар....8) ну а зависание определяем как "нет посылки уведомления за определенный переод"....

надеюсь доступно расписал...К слову, вариант простой (с двумя потоками) реализуется очень несложно....

Этот вариант звучит очень интересно, только с потоками никогда работать не приходилось, и потому подход не до конца понятен. Где про это можно почитать? 

msdn ? Там не очень и сложно... надо знать-то
CreateThread, Terminatethread, SetEvent, CreateEvent, WaitForSingleObject
посмотрите в гугле по поводу использования этих функций....

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

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

Насколько я понимаю, "хоть как-то" оно работает как раз в данный момент   
Эээ... А зачем бороться со следствием, если необходимо бороться с причиной? Почему бы просто не починить\переписать ту функцию на фокспро, которая вызывает зависание? Может стоит всего лишь более детально изучить причины (к примеру, у меня в 99% случаев зависаний моих программ причиной был ненулевой радиус кривизны моих же рук)? Еще как вариант - написать саму программу синхронизации баз данных на том же билдере или че там еще - уж это-то, как мне кажется, если и не менее трудоемкое, то хотя бы более правильное решение...

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

ama_kid, абсолютно согласен, надо ту функцию на Фокспро отдебажить, и свести рик зависания к минимуму!
убивать процесс синхронизации черевато потерями данных.

От себя могу предложить:
Если фокс про поддеживает Таймеры, то можно просто сделать самослежение.
Ведь в виндовсе таймеры работают отдельным процессом и могут как то повлиять на "хозяина"

Написано все это на досовом фоксе 2.6, так что по поводу таймера сомневаюсь... как ее отлаживать ума не приложу... программа может работать нормально, потом ни с того ни с сего подвиснуть, причем на любом этапе синхронизации. Может и работать целый день нормально. Никаких закономерностей обнаружить не удалось... И как прикажете отлаживать?..
Потом, по поводу потери данных - программа сначала бд архивирует (с помощью досовского рара), потом передает по фтп в какой-то временный каталог, на другой стороне уже другая программа продолжает работу с архивом. Т.е. синхронизация идет таким образом.
Да и убивать программу сейчас все-равно приходится, только лишь вручную. Почему же это дело в таком случае не автоматизировать? По крайней мере это будет решение, пока не будет сделана или новая программа синхронизации, или доделана старая. Просто сейчас, в таком состоянии совсем плохо...

Dieselist, ну ладно если уж так не хочется исследовать проблему, то вот тебе пример процесс-киллера - может пригодится. Он, правда, на дельфях, но кода там минимум и все вроде не сложно, апишные функции - они все равно одинаковые...

Это сообщение отредактировал(а) ama_kid - 8.11.2007, 12:51

Если не удалось найти закономерностей, надо искать, какие события или сочетания условий в системе возникают случайно.
Я вот писал прогу, которая принимала звонки и тоже работала с БД. Так вот там тоже было несколько процессов и она тоже висла абсолютно в произвольные моменты. Я тоже грешил на синхронизацию и парился... Но потом оказалось, что просто косяк в обработке одной строки, когда поступал звонок с номера с антиопределителем. Исправить это было гораздо легче, чем следить и перезапускать процессы

Согласен, ведь его программа не имеет дело к примеру с погодой, которая резко меняется.
Она имеет дело именно с базой данных, которая сама по себе есть творение программы.

Не поленись составь подробный лог какжого процесса.. это поможет тебе найти закономерность.