Здравствуйте, гость ( Вход | Регистрация )
Iron Bug | Дата 4.12.2015, 19:56 |
я не понимаю, о чём вообще разговор. программирую уже более 20 лет. всякие области применения были: и микроконтроллеры, и промышленная автоматика, управление железом в риалтайме, и серверные приложения, которые работают без перерыва годами, и кернельные модули, и драйверы. всё под разные системы или кроссплатформу. и как-то нигде не возникало проблем, ничего не падало. просто думать надо головой, когда код пишешь. и тестировать тщательно. что касается линюкса, то если семафор по каким-то причинам "завис", то его можно сбросить утилитой ipcrm. в posix именованному мьютексу можно установить флаг PTHREAD_MUTEX_ROBUST и тогда после ненормального завершения потока его хэндлер закроется системой. в венде лучше использовать мьютексы, на них хэндлы всегда закрываются после завершения потока. соответственно, в кроссплатформе тоже лучше использовать мьютексы. |
|
wiz29 | Дата 4.12.2015, 12:02 |
обычно отслеживание запуска нескольких экземпляров приложения реализуют с помощью именованных мьютексов. это самый стандартный метод. а активация окна может производиться любым методом межпроцессного взаимодействия (например, через отправку сигналов). Это допустить можно, однако мир не идеален и это для B2C не очень удачное решение, в случае если приложение развалится. (пользователю потом не объяснишь, что надо ОС перезапустить чтоб перезапустить программу) Для OS X напрример можно записать в файл настроек ID процесса и его проверять при запуске. Для nix систем подозреваю можно сделать тоже самое. Такое решение более надежно в этом случае. Но вариантов решения 1 и той же задачи всегда много. |
|
lanz | Дата 4.12.2015, 9:11 |
Цитата просто не надо писать приложения, которые крашатся Вот и мой начальник так говорит все время Меня смутила секция Platform-Specific Behaviour вот отсюда: http://doc.qt.io/qt-4.8/qsystemsemaphore.html Цитата Windows: QSystemSemaphore does not own its underlying system semaphore. Windows owns it. This means that when all instances of QSystemSemaphore for a particular key have been destroyed, either by having their destructors called, or because one or more processes crash, Windows removes the underlying system semaphore. и Цитата Unix: QSystemSemaphore owns the underlying system semaphore in Unix systems. This means that the last process having an instance of QSystemSemaphore for a particular key must remove the underlying system semaphore in its destructor. If the last process crashes without running the QSystemSemaphore destructor, Unix does not automatically remove the underlying system semaphore, and the semaphore survives the crash. Правда если внимательно читать: Цитата When a process using QSystemSemaphore terminates for any reason, Unix automatically reverses the effect of all acquire operations that were not released. Thus if the process acquires a resource and then exits without releasing it, Unix will release that resource. Таким образом и Win и Unix отпускают захваченные мьютексы, просто Windows удаляет его сам когда завершается/крашится последний процесс, а в Unix этого не происходит. Цитата To protect against this, the first process to create a semaphore for a particular key (usually a server), must pass its access mode as Create, which will force Unix to reset the resource count in the underlying system semaphore. Насколько я понимаю с точки зрения захвата/освобождения все одинаково, единственная разница в ownership, но это уже вкусовщина. |
|
Iron Bug | Дата 4.12.2015, 6:39 |
Насколько я помню, именованные мьютексы под линукс не освобождаются если процесс крашится, поэтому не очень удобно. в любой системе это так. потому что мьютекс не принадлежит процессу, это объект ядра. просто не надо писать приложения, которые крашатся |
|
lanz | Дата 3.12.2015, 23:54 |
Насколько я помню, именованные мьютексы под линукс не освобождаются если процесс крашится, поэтому не очень удобно. | |
Iron Bug | Дата 3.12.2015, 23:12 |
обычно отслеживание запуска нескольких экземпляров приложения реализуют с помощью именованных мьютексов. это самый стандартный метод. а активация окна может производиться любым методом межпроцессного взаимодействия (например, через отправку сигналов). | |
lanz | Дата 3.12.2015, 18:00 |
То что предложил wiz29 эквивалентно (с точностью до изоморфизма ), разница в транспорте сообщения только. Поэтому если реализовано сообщение через общую память, то проще. | |
MishaUA | Дата 3.12.2015, 15:47 |
Сделал как написал lanz. По-моему, эт самый простой способ | |
wiz29 | Дата 3.12.2015, 13:43 |
Как вариант можно использовать именованный канал (pipe). Если экземпляру приложения не удалось подключиться к созданному каналу, то оно создает такой канал и считает, что это 1й экземпляр приложения. Когда обнаруживается повторный запуск, 2й экземпляр спокойно подключается к данному каналу и отправляет нужную команду основному приложению. Такую схему так же удобно использовать для открытия файла по клику в Windows системах когда нужно иметь только 1 экземпляр приложения. В команде в этом слаче передается путь к файлу, который надо открыть. |
|
lanz | Дата 3.12.2015, 9:50 |
Записывайте в общую память флаг "активируйся!". И пусть приложение опрашивает этот флаг. Как только он поднят, вызываем activateWindow, сбрасываем флаг. | |
Просмотр темы полностью (откроется в новом окне) | |
Текстовая версия | Сейчас: 29.3.2024, 2:07 |