Имеется некая программа. Она может запускаться в различных конфигурациях, которые определяются конкретным запуском (строго НЕинтерактивно на уровне запускаемого приложения) - например с разными параметрами командной строки, из разных каталогов, несколько старт-модулей, запускающих главный модуль в особой среде и пр. Это происходит в ОС семейства WindowsNT.

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

Единственное видимое (пока, во всяком случае) решение - изготовление некоей программной обертки-запускателя (скриптового или ЕХЕ), которая будет выполнять функции по отслеживанию дублей. Считаем, что если такой запускатель есть, мимо него запуск производиться не будет (например каждая конфигурация стартует своим ярлыком или запускатель будет просить указать конфигурацию, как это сделано, скажем, в 1С).

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

Помогите разработать алгоритм регистрации и верификации работающих конфигураций...

========================================================

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

Цитата

Сложности - во-первых, нет ограничения на тип запускаемого приложения (ДОС, консольное, оконное, безоконное)

не уверен, но разве важно, какой тип приложения, для функций типа ShellExecute или CreateProcess?

Цитата

во-вторых, в любой момент любая из конфигураций может скоропостижно покинуть RAM, не успев об этом сообщить

ну процесс в любом случае пропадет (или программа может некорректно завершиться, оставшись в памяти?)
а значит, всякие функции типа WaitForSingleObject, по идее, должны работать

Добавлено @ 11:10

Akina в Windows NT есть Мьютексы - это вроде уникального сосотяния в системе в виде строки, может это подойдет?

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

Цитата(maxim1000 @ 27.7.2005, 12:01)

разве важно, какой тип приложения

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

Цитата(maxim1000 @ 27.7.2005, 12:01)

всякие функции типа WaitForSingleObject, по идее, должны работать

Скоропостижная смерть ака выгрузка возможны, пугает

Цитата

If this handle is closed while the wait is still pending, the function's behavior is undefined.

Цитата

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

я имел в виду привязаться к HANDLE процесса (его можно получить при использовании CreateProcess и, по-моему, ShellExecute)

Цитата

If this handle is closed while the wait is still pending, the function's behavior is undefined

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

Цитата(Akina @ 27.7.2005, 12:27)

не опускаясь до работы с тредами

А что плохого в тредах?

Если всё это реализовывать на Java, то можно достаточно элегантно ситуацию разрулить в виде тредов. Правда, тогда понадобится некоторый общий процесс, через который будут запускаться все конфигурации, организованные в виде тредов. Он бы в карте хранил всю информацию о тредах и их конфигурациях и страховал бы от дублирования тредов с одинаковой конфигурацией, а мёртвые треды удалял бы из карты. Этот процесс мог бы удаляться, когда видит, что все треды умерли, автоматически.

Наверняка похожим образом можно и в .NET`е сделать.

Если это совсем неприемлемо, тогда не знаю...

Цитата(Akina @ 27.7.2005, 11:27)

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

Ну так использование Mutexов это практически то же самое, только гораздо естественней!

Для каждой конфигурации создаётся мьютекс с уникальным именем.

Например: MyApplicationMutexNNN, где NNN - номер конфигурации.

Примерно так:

Код

char str[256]; sprintf(str,"MyApplicationMutex%i", iConfigCode); HANDLE hConfigMutex = CreateMutex(NULL, TRUE, str); if (GetLastError() == ERROR_ALREADY_EXISTS)     throw ("Эта конфигурация уже запущена!!!");

Никаких потоков, никаких усложнений -- обычная системная функция.

Цитата

понадобится некоторый общий процесс

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

Цитата

Для каждой конфигурации создаётся мьютекс с уникальным именем

А как он себя поведет при внезапной смерти экземпляра приложения, для которого создан? тоже помре?

Akina

Цитата(Akina @ 28.7.2005, 18:45)

А как он себя поведет при внезапной смерти экземпляра приложения, для которого создан? тоже помре?

Вот не помню.

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

Даже если по каким-то причинам (фаза Луны, например) не уничтожат после закрытия процесса, то можно сделать такую проверку (и это, наверно, даже более правильный способ):

Код

char str[256]; sprintf(str,"MyApplicationMutex%i", iConfigCode); HANDLE hConfigMutex = CreateMutex(NULL, TRUE, str); if (WaitForSingleObject(hConfigMutex, 0) == WAIT_TIMEOUT)        throw ("Эта конфигурация уже запущена!!!");

Т.е. я вместо GetLastError просто проверяю: свободен ли мьютекс или нет.
Если мы его создали впервые, то мы и являемся его хозяинов и Wait вернёт WAIT_OBJECT_0.
Если кто-то другой его создал и его хозяин, то вернёт WAIT_TIMEOUT.
А если его хозяин уже подох, а мьютех ещё существует, то WaitForSingleObject возвращает WAIT_ABANDONED.

Это сообщение отредактировал(а) Дрон - 28.7.2005, 18:05

Цитата(Akina @ 28.7.2005, 17:45)

Цитата (Се ля ви @ 28.7.2005, 01:03) понадобится некоторый общий процесс Как я уже сказал, любой процесс может умереть, в т.ч. этот. При старте следующей копии приложения запустится копия этого общего процесса, не найдя себя в памяти, она останется... но откуда она возьмет данные о том что ДО НЕЕ было запущено? и проверит что между смертью ее предшественника и ее собсным стартом не был завершен один из экземпляров? и что эта скоропостижная смерть предшественника - не нажатие на ресет...

Ну, например, свою карту она может сериализовывать в базу или на диск в специальную папку при каждом изменении и/или циклически через фиксированный интервал времяни - тогда даже если процесс умрёт, он сможет восстановить всю информацию о работающих тредах. Вроде, был такой способ сериализации, когда остаются ссылки на объекты, а не сериализуется всё дерево...

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

Цитата(maxim1000 @ 29.7.2005, 13:09)

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

Нет, помереть он может сам, без вмешательства извне... в том и дело, что надо предусмотреть все мыслимые и немыслимые варианты и их сочетания.
Это же под Windows...

Цитата

Если мы его создали впервые, то мы и являемся его хозяинов и Wait вернёт WAIT_OBJECT_0. Если кто-то другой его создал и его хозяин, то вернёт WAIT_TIMEOUT. А если его хозяин уже подох, а мьютех ещё существует, то WaitForSingleObject возвращает WAIT_ABANDONED.

О! уже ближе к телу... спасибо...