Непонятно зачем порезали Event'ы
Именованый межпроцессный Event создать нельзя. Остался только Mutex именованый но этого не достаточно.
А если потребуется например такая фича, один процесс запускает другой процесс и ждет пока он не просигнализирует об окончании загрузки.
Есть два варианта либо в цикле со Sleep'ами опрашивать пока загружаемый процесс Mutex не захватит. Либо по человечески сделать — через WinAPI ManualResetEvent сделать. Только вот затрудняюсь предположить не будет ли конфликтов каких то с .Net Threading, если WinAPI синхронизацию использовать. Не шаманство ли это?
Здравствуйте, Silver_s, Вы писали:
S_>Непонятно зачем порезали Event'ы S_> Именованый межпроцессный Event создать нельзя. Остался только Mutex именованый но этого не достаточно. S_> А если потребуется например такая фича, один процесс запускает другой процесс и ждет пока он не просигнализирует об окончании загрузки. S_> Есть два варианта либо в цикле со Sleep'ами опрашивать пока загружаемый процесс Mutex не захватит. Либо по человечески сделать — через WinAPI S_> ManualResetEvent сделать. Только вот затрудняюсь предположить не будет ли конфликтов каких то с .Net Threading, если WinAPI синхронизацию S_> использовать. Не шаманство ли это?
С именоваными event'ами проблема на платформах, отличных от Win32. Да и начальная специфика проектов .Net (веб-сервисы, ASP.NET) не предполагала широкой межпроцессной синхронизации. Мы сделали свой человеческий Event, наследника от WaitHandle, через DLLImport. Там, правда, возникнут сложности с переносом на MONO и прочее, но это — как доберемся, решим. Named event'ы на базе посиксных и sys5 семафоров уже есть, так что перетянем в C# ...
Здравствуйте, mayevski, Вы писали:
M>С именоваными event'ами проблема на платформах, отличных от Win32. Да и начальная специфика проектов .Net (веб-сервисы, ASP.NET) не предполагала широкой межпроцессной синхронизации...
Наверное из-за этого они отказались от именованых ивентов.
Шаманить с WinAPI тоже не хочется, т.к. задача того не оправдывает.
А задачка то в общем то примитивная. В небольшой dll'ке с интерфейсами Remoating объекта, сделать запуск известного процесса который эти Remoating объекты регистрирует и дождаться пока эти WellKnown типы появятся. Сам Remoating не знает какие у него WellKnown типы есть. По крайней мере я не неашел таких фичей.
А проверять наличие типов на локальной машине, создавая объекты и ловя exeption после таймаутов от неудачных обращений к их функциям не хорошо.
Остается такой вариант. Клиенту в цикле со Sleep'ами 10 милисекунд. Пытаться захватить именованый Mutex, если получается, то сразу освобождаем и дальше крутим цикл пока он не будет занят.
А на серваке после регистрации WellKnown типов, занимаем этот Mutex.
Ну и еще второй Mutex на серваке перед входом в код регистрации типов и каналов,чтобы защитить от входа из второй копии. Иначе рушится оба сервера.
Здравствуйте, Silver_s, Вы писали:
S_> Остается такой вариант. Клиенту в цикле со Sleep'ами 10 милисекунд. Пытаться захватить именованый Mutex, если получается, то сразу освобождаем и дальше крутим цикл пока он не будет занят.
Угу. Только вот (опять таки), WaitOne в .NET CF не имеет параметра ожидания и там тоже приходится делать через p/invoke.
Здравствуйте, Silver_s, Вы писали:
S_> Наверное из-за этого они отказались от именованых ивентов. S_>Шаманить с WinAPI тоже не хочется, т.к. задача того не оправдывает.
Да там шаманства то особого нет, почти все есть. Если нужно могу завтра тебе исходники готового кинуть.
S_> Остается такой вариант. Клиенту в цикле со Sleep'ами 10 милисекунд. Пытаться захватить именованый Mutex, если получается, то сразу освобождаем и дальше крутим цикл пока он не будет занят. S_> А на серваке после регистрации WellKnown типов, занимаем этот Mutex. S_> Ну и еще второй Mutex на серваке перед входом в код регистрации типов и каналов,чтобы защитить от входа из второй копии. Иначе рушится оба сервера.
Можно проще — на сервере просто мьютекс создавать по завершению инициализации, а на клиенте пытаться открыть.
Здравствуйте, AndrewVK, Вы писали:
AVK>Можно проще — на сервере просто мьютекс создавать по завершению инициализации, а на клиенте пытаться открыть.
В данном случае, в общем то это подойдет. Если не считать мелкие неприятности, что цикл ожидания нужно крутить. И с несколькими ожидающими процессами накладка может получиться, в данном случае ее вероятность ничтожно мала, да и не очень критично это.
Но в общем случае черз такие Mutex'ы невозможно надежно события передавать из одного процесса в другие. Их немного для другого приспособили.
Mutex'ы ведь не дают ждать занятия, а только освобождения. Если 2 приемника ждут когда источник сигнала займет Mutex, то они должны пытаться его занять, если получилось значит быстренько его освобождаем и дальше цикл ожидания крутим. Но даже если быстро обратно освобождать, другой процесс тоже ждущий когда Mutex станет занятым может ошибочно ложный сигнал получить.
А как можно проверить состояние Mutexа и чтобы он при этом не включился (не захватился) — вроде никак.
