Сообщение Re[31]: Windows захватили инопланетяне? от 24.01.2020 23:26
Изменено 24.01.2020 23:41 blp
Re[31]: Windows захватили инопланетяне?
Здравствуйте, Sinclair, Вы писали:
S>Ну вот мне и интересно поговорить с точки зрения того, кто архитектурит.
Да оно понятно. Все хотят говорить про архитектуру, тольку уровень "разговоров" все равно на уровне джуниоров, которым ничего архитектурить не дают.
lp>>Ну, ее придумали в результате планирования новых фич, которые нужны были бизнесу. Бизнесу нужна была изоляция процессов для большей reliability и меньшего количества крашей. Проанализировали дампы — телеметрию и приняли решение.
S>Отлично. Почему не устроила изоляция при помощи worker process, как это сделано в IIS? Почему все эти процессы надо было оформлять именно как сервисы?
Я уже это объяснял, но вы не поняли. Не "не устроила изоляция при помощи worker process" — системный код просто нельзя запихать в просто приложения, чтобы он корректно стартовал и деинициализировался при логоне-логоффе. Ваши попытки сформулировтаь, как именно это сделать, приводили пока либо
— к решению другой задачи (рисовать лошадку) — per-user стейт держать в одном процессе-сервисе, а не process per user session — прямо противоречит изоляции по процессам
— к предложению просто неработающих решений на базе приложений, которые будут "как-то" запускаться при логоне и "как-то" потом завершаться — когда были заданы детальные вопросы, вы на них не ответили.
> Ну, и по-прежнему непонятно, как это повлияет на количество крэшей.
Ну, непонятно так непонятно. Жизнь-боль и т. д.
S>Если сервис CDPSvc у пользователя Васи крэшится раз в неделю из-за бага в сервисе, то как перенос этого бага в отдельный сервис поможет что-то там сократить? Он же по-прежнему будет крэшиться раз в неделю.
Вместе с CDPSvc будут потенциально крашиться зависящие от него процессы. Не только Васи, но и у Пети, сидящем на той же машине по RDP.
После рефакторинга никто, кроме Васи зааффекчен не будет (если ситуация, приводящая к крашу, возникает в коде. который выполняется для Васи).
Ну хоть немного головой думать надо...
>>>Вы точно уверены, что CDPUserSVC — это рефакторинг кода CDPSvc,
blp>>Да.
S>Можете раскрыть источник своей уверенности?
Little birdie told me.
blp>>Не понял, какие еще приложения? Раньше был просто CDPSvc
S>Ну, я не знаю
Ну вот вы не знаете, но зачем-то какую-то чушь порете и потом просите что-то вам доказывать и детально разжевывать, объясняя, почему то чушь. Это до какой-то степени забавно, но я уже устал.
>Каким образом CDPSvc раньше взаимодействовал с десктопами пользователей?
Предлагаю самостоятельно попробовать найти ответ на этот вопрос. Это не сложно.
blp>>я общаюсь на уровне собеседников.
S>Не, вы лучше на своём уровне общайтесь.
На более высоком уровне имеет смысл общаться с людьми, которые
— сами хорошо разбираются в предмете
— в состоянии хорошо в нем разобраться после указания на доступные материалы
— задают интересные и оригинальные вопросы
ничего из вышеописанного не происходит, увы.
Серьезно заниматься тут просвещением ширнармасс и борьбой с религиознвым мракобесием можно только за деньги =)
S>Цитирую:
Здесь нет ничего конкретного. На последующий вопрос как именно вы будете без сервисов процессы запускать и трекать на каждый логин логофф вы ничего путного не ответили. "Сделаем как в iis " не ответ потому что в iis не надо делать per-session. А если делать один большой сервис, то это решение другой задачи, изоляции не будет.
S>Нет, не в курсе. Ну, то есть те части продукции Microsoft, которые наблюдаю лично я
О, что наблюдаете лично вы это несомненно очень важно. Может, вы смотрите на какой-нибудь адов продукт типа шарепоинта. Как это относится к разработке центральных компонентов ОС, сервисов и т д — неведомо. Автотесты на API у них какие-то. Какой API, где документирован, сколько человек его использует...
S>Если у вас есть какая-то инсайдерская инфа — делитесь, это как раз интересно.
Может и интересно, только не в коня корм. Думаю, не стоит, да и нельзя наверное.
\blp>>Это почему? Потому что вам так удобнее?
S>Нет, потому что вы выбрали аргументацию про изоляцию, а не про взаимодействие с десктопом.
Мы с самого начала обсуждаем как сделать чтобы системный код был изолирован per-user-logon-session. Срач начался с "чем это лучше чем таски или банальный авторан?"
Вы зачем-то привели нерелеватный пример iis, который просто создает w3wp процессы, никак к логон сессям не привязанные. Если бы надо было создавать несколько процессов, никак не привязаных к циклу логина — логоффа — оно было бы релеватно хоть как-то.
S>А в чём специфика проблем per-user-logon-session?
Зачем вы меня спрашиваете? Себя спросите.
> И почему надо было именно per user logon session, а не per user?
Потому что жизнь такая
>Если я, скажем, дважлы по RDP зайду на одну машину — сколько экземпляров per-user сервиса будет создано?
Зависит от многих факторов. Multiple different RDP sessions per user вполне возможны. HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" fSingleSessionPerUser -> 0 и т д
S>Хороший вопрос. А где берётся токен для per-user service?
Где же он действительно берется? Задайте себе еще более интересный вопрос — где берется токен, под которым запускаются вообще все юзерские приложения, explorer.exe там и т д. Где берется токен, используемый для per-user сервисов?
S>>>Нет, мы говорим не о шатдауне, а о logoff.
Вы просто говорите о вещах, в которых не разбираетесь.
S>Ну, на мой взгляд шатдаун радикально отличается тем
Кого волнует, чемони на ваш взгляд отличаются
S>А с логоффом-то что не так?
Логофф — это такой тип шатдауна.
> Грубо говоря, если у меня бежит обычное приложение в рамках пользовательской сессии, и ему намекают про WM_QUERYENDSESSION, то нужно по-быстрому отдать данные сервису (а это можно сделать _очень_ быстро, даже если этих данных там гигабайт), и быть готовым к WM_ENDSESSION/WM_CLOSE. Пусть пользователь себе логоффится, а записью данных будет заниматься сервис, которому пользовательская сессия не нужна.
Да, давайте опять сделаем центральный сервис вместо того, чтобы изолировать процессы разный логон-сессий. Потому что цикровая лошать умеет только бегать по кругу. Мне уже надоело по третьему разу это комментировать.
S>Вроде всё норм. А вот зачем задерживать именно логофф — тут я не понимаю. Как, впрочем, не понимаю, какими средствами это можно сделать в рамках хоть приложения, хоть сервиса.
Ну, не понимаете, так не понимаете. Что ж тут поделать. Ссылки я давал — перечитайте мои ответы со ссылками и содержимое ссылок — может, поможет, не знаю. Второй раз разжевывать я не буду. Sapienti sat.
blp>>Читать MSDN все-таки придется, если хотите разобраться.
S>Ок, где именно читать?
S>Тогда о чём вообще вы говорили в рамках идеи задержать логофф? Вы же хотите именно логофф задерживать — как это делается?
при логоффе per-user-session сервисы останавливаются, после того, как завершены все приложения, относящиеся к сессии.
Пока сервисы не остановятся, логофф не заканчивается.
Таймаут на свою остановку сервис определяет сам, и он может быть довольно большим (3 минуты по умолчанию). Если бы вы читали ссылки, что я даю, вы бы это и так знали.
>>>Напомню, что мы обсуждаем именно logoff
blp>>В windows logoff — это такой тип шатдауна, как бы странно это ни звучало. Текст по ссылке вы не читали либо читали невнимательно. Даже сам логофф можно выполнить командой shutdown /l
S>По ссылке написано, что приложение не может отличит логофф от шатдауна.
Ага. В голове ничего не щелкнуло?
S>Я по-прежнму не понимаю, почему логофф должен прибить мои системные процессы?
Потому что у вас системный процесс со временем жизни в юзерскую логон-сессию? Для изоляции, помните?
S>Почему же не надо? Я всё прочитал.
Ну значит прочитали и не поняли.
>Приложение, если ему надо, может получить ажно 30 секунд на выполнение "последней воли".
А таймаут остановки сервиса определяете самим сервисом. Улавливаете?
> Не вижу никакого смысла исполнять критический код в рамках интерактивной сессии
Ну не видите и не видите. Конечно, то, чего вы не видите, не существует.
blp>>Никаких проблем. "Все отнять и поделить" (с) Шариков.
S>Ну, в MSDN написано именно так
.
Нет, в MSDN так не написано.
S>Ок, жаль. А только было началось что-то интересное.
Се ля ви.
S>Если уж вас потянуло на откровенность — расскажите, почему не стали именовать сервисы в стиле CDPUserSvc$3 — ведь их же ровно 1 на сессию, конфликта имён не будет. Зато угадывать имена сервисов стало бы проще, можно обойтись без tasklist, одним qwinsta.
Потому что LUID в имени сервиса — гарантированно уникальный на каждый логон эвент на все время, пока машину не перезагрузят, а session id может переиспользоваться в ряде случаев.
S>Ну вот мне и интересно поговорить с точки зрения того, кто архитектурит.
Да оно понятно. Все хотят говорить про архитектуру, тольку уровень "разговоров" все равно на уровне джуниоров, которым ничего архитектурить не дают.
lp>>Ну, ее придумали в результате планирования новых фич, которые нужны были бизнесу. Бизнесу нужна была изоляция процессов для большей reliability и меньшего количества крашей. Проанализировали дампы — телеметрию и приняли решение.
S>Отлично. Почему не устроила изоляция при помощи worker process, как это сделано в IIS? Почему все эти процессы надо было оформлять именно как сервисы?
Я уже это объяснял, но вы не поняли. Не "не устроила изоляция при помощи worker process" — системный код просто нельзя запихать в просто приложения, чтобы он корректно стартовал и деинициализировался при логоне-логоффе. Ваши попытки сформулировтаь, как именно это сделать, приводили пока либо
— к решению другой задачи (рисовать лошадку) — per-user стейт держать в одном процессе-сервисе, а не process per user session — прямо противоречит изоляции по процессам
— к предложению просто неработающих решений на базе приложений, которые будут "как-то" запускаться при логоне и "как-то" потом завершаться — когда были заданы детальные вопросы, вы на них не ответили.
> Ну, и по-прежнему непонятно, как это повлияет на количество крэшей.
Ну, непонятно так непонятно. Жизнь-боль и т. д.
S>Если сервис CDPSvc у пользователя Васи крэшится раз в неделю из-за бага в сервисе, то как перенос этого бага в отдельный сервис поможет что-то там сократить? Он же по-прежнему будет крэшиться раз в неделю.
Вместе с CDPSvc будут потенциально крашиться зависящие от него процессы. Не только Васи, но и у Пети, сидящем на той же машине по RDP.
После рефакторинга никто, кроме Васи зааффекчен не будет (если ситуация, приводящая к крашу, возникает в коде. который выполняется для Васи).
Ну хоть немного головой думать надо...
>>>Вы точно уверены, что CDPUserSVC — это рефакторинг кода CDPSvc,
blp>>Да.
S>Можете раскрыть источник своей уверенности?
Little birdie told me.
blp>>Не понял, какие еще приложения? Раньше был просто CDPSvc
S>Ну, я не знаю
Ну вот вы не знаете, но зачем-то какую-то чушь порете и потом просите что-то вам доказывать и детально разжевывать, объясняя, почему то чушь. Это до какой-то степени забавно, но я уже устал.
>Каким образом CDPSvc раньше взаимодействовал с десктопами пользователей?
Предлагаю самостоятельно попробовать найти ответ на этот вопрос. Это не сложно.
blp>>я общаюсь на уровне собеседников.
S>Не, вы лучше на своём уровне общайтесь.
На более высоком уровне имеет смысл общаться с людьми, которые
— сами хорошо разбираются в предмете
— в состоянии хорошо в нем разобраться после указания на доступные материалы
— задают интересные и оригинальные вопросы
ничего из вышеописанного не происходит, увы.
Серьезно заниматься тут просвещением ширнармасс и борьбой с религиознвым мракобесием можно только за деньги =)
S>Цитирую:
Здесь нет ничего конкретного. На последующий вопрос как именно вы будете без сервисов процессы запускать и трекать на каждый логин логофф вы ничего путного не ответили. "Сделаем как в iis " не ответ потому что в iis не надо делать per-session. А если делать один большой сервис, то это решение другой задачи, изоляции не будет.
S>Нет, не в курсе. Ну, то есть те части продукции Microsoft, которые наблюдаю лично я
О, что наблюдаете лично вы это несомненно очень важно. Может, вы смотрите на какой-нибудь адов продукт типа шарепоинта. Как это относится к разработке центральных компонентов ОС, сервисов и т д — неведомо. Автотесты на API у них какие-то. Какой API, где документирован, сколько человек его использует...
S>Если у вас есть какая-то инсайдерская инфа — делитесь, это как раз интересно.
Может и интересно, только не в коня корм. Думаю, не стоит, да и нельзя наверное.
\blp>>Это почему? Потому что вам так удобнее?
S>Нет, потому что вы выбрали аргументацию про изоляцию, а не про взаимодействие с десктопом.
Мы с самого начала обсуждаем как сделать чтобы системный код был изолирован per-user-logon-session. Срач начался с "чем это лучше чем таски или банальный авторан?"
Вы зачем-то привели нерелеватный пример iis, который просто создает w3wp процессы, никак к логон сессям не привязанные. Если бы надо было создавать несколько процессов, никак не привязаных к циклу логина — логоффа — оно было бы релеватно хоть как-то.
S>А в чём специфика проблем per-user-logon-session?
Зачем вы меня спрашиваете? Себя спросите.
> И почему надо было именно per user logon session, а не per user?
Потому что жизнь такая
>Если я, скажем, дважлы по RDP зайду на одну машину — сколько экземпляров per-user сервиса будет создано?
Зависит от многих факторов. Multiple different RDP sessions per user вполне возможны. HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" fSingleSessionPerUser -> 0 и т д
S>Хороший вопрос. А где берётся токен для per-user service?
Где же он действительно берется? Задайте себе еще более интересный вопрос — где берется токен, под которым запускаются вообще все юзерские приложения, explorer.exe там и т д. Где берется токен, используемый для per-user сервисов?
S>>>Нет, мы говорим не о шатдауне, а о logoff.
Вы просто говорите о вещах, в которых не разбираетесь.
S>Ну, на мой взгляд шатдаун радикально отличается тем
Кого волнует, чемони на ваш взгляд отличаются
S>А с логоффом-то что не так?
Логофф — это такой тип шатдауна.
> Грубо говоря, если у меня бежит обычное приложение в рамках пользовательской сессии, и ему намекают про WM_QUERYENDSESSION, то нужно по-быстрому отдать данные сервису (а это можно сделать _очень_ быстро, даже если этих данных там гигабайт), и быть готовым к WM_ENDSESSION/WM_CLOSE. Пусть пользователь себе логоффится, а записью данных будет заниматься сервис, которому пользовательская сессия не нужна.
Да, давайте опять сделаем центральный сервис вместо того, чтобы изолировать процессы разный логон-сессий. Потому что цикровая лошать умеет только бегать по кругу. Мне уже надоело по третьему разу это комментировать.
S>Вроде всё норм. А вот зачем задерживать именно логофф — тут я не понимаю. Как, впрочем, не понимаю, какими средствами это можно сделать в рамках хоть приложения, хоть сервиса.
Ну, не понимаете, так не понимаете. Что ж тут поделать. Ссылки я давал — перечитайте мои ответы со ссылками и содержимое ссылок — может, поможет, не знаю. Второй раз разжевывать я не буду. Sapienti sat.
blp>>Читать MSDN все-таки придется, если хотите разобраться.
S>Ок, где именно читать?
S>Тогда о чём вообще вы говорили в рамках идеи задержать логофф? Вы же хотите именно логофф задерживать — как это делается?
при логоффе per-user-session сервисы останавливаются, после того, как завершены все приложения, относящиеся к сессии.
Пока сервисы не остановятся, логофф не заканчивается.
Таймаут на свою остановку сервис определяет сам, и он может быть довольно большим (3 минуты по умолчанию). Если бы вы читали ссылки, что я даю, вы бы это и так знали.
>>>Напомню, что мы обсуждаем именно logoff
blp>>В windows logoff — это такой тип шатдауна, как бы странно это ни звучало. Текст по ссылке вы не читали либо читали невнимательно. Даже сам логофф можно выполнить командой shutdown /l
S>По ссылке написано, что приложение не может отличит логофф от шатдауна.
Ага. В голове ничего не щелкнуло?
S>Я по-прежнму не понимаю, почему логофф должен прибить мои системные процессы?
Потому что у вас системный процесс со временем жизни в юзерскую логон-сессию? Для изоляции, помните?
S>Почему же не надо? Я всё прочитал.
Ну значит прочитали и не поняли.
>Приложение, если ему надо, может получить ажно 30 секунд на выполнение "последней воли".
А таймаут остановки сервиса определяете самим сервисом. Улавливаете?
> Не вижу никакого смысла исполнять критический код в рамках интерактивной сессии
Ну не видите и не видите. Конечно, то, чего вы не видите, не существует.
blp>>Никаких проблем. "Все отнять и поделить" (с) Шариков.
S>Ну, в MSDN написано именно так
.Нет, в MSDN так не написано.
S>Ок, жаль. А только было началось что-то интересное.
Се ля ви.
S>Если уж вас потянуло на откровенность — расскажите, почему не стали именовать сервисы в стиле CDPUserSvc$3 — ведь их же ровно 1 на сессию, конфликта имён не будет. Зато угадывать имена сервисов стало бы проще, можно обойтись без tasklist, одним qwinsta.
Потому что LUID в имени сервиса — гарантированно уникальный на каждый логон эвент на все время, пока машину не перезагрузят, а session id может переиспользоваться в ряде случаев.
Re[31]: Windows захватили инопланетяне?
Здравствуйте, Sinclair, Вы писали:
S>Ну вот мне и интересно поговорить с точки зрения того, кто архитектурит.
Да оно понятно. Все хотят говорить про архитектуру, тольку уровень "разговоров" все равно на уровне джуниоров, которым ничего архитектурить не дают.
lp>>Ну, ее придумали в результате планирования новых фич, которые нужны были бизнесу. Бизнесу нужна была изоляция процессов для большей reliability и меньшего количества крашей. Проанализировали дампы — телеметрию и приняли решение.
S>Отлично. Почему не устроила изоляция при помощи worker process, как это сделано в IIS? Почему все эти процессы надо было оформлять именно как сервисы?
Я уже это объяснял, но вы не поняли. Не "не устроила изоляция при помощи worker process" — системный код просто нельзя запихать в просто приложения, чтобы он корректно стартовал и деинициализировался при логоне-логоффе. Ваши попытки сформулировтаь, как именно это сделать, приводили пока либо
— к решению другой задачи (рисовать лошадку) — per-user стейт держать в одном процессе-сервисе, а не process per user session — прямо противоречит изоляции по процессам
— к предложению просто неработающих решений на базе приложений, которые будут "как-то" запускаться при логоне и "как-то" потом завершаться — когда были заданы детальные вопросы, вы на них не ответили.
> Ну, и по-прежнему непонятно, как это повлияет на количество крэшей.
Ну, непонятно так непонятно. Жизнь-боль и т. д.
S>Если сервис CDPSvc у пользователя Васи крэшится раз в неделю из-за бага в сервисе, то как перенос этого бага в отдельный сервис поможет что-то там сократить? Он же по-прежнему будет крэшиться раз в неделю.
Вместе с CDPSvc будут потенциально крашиться зависящие от него процессы. Не только Васи, но и у Пети, сидящем на той же машине по RDP.
После рефакторинга никто, кроме Васи зааффекчен не будет (если ситуация, приводящая к крашу, возникает в коде. который выполняется для Васи).
Ну хоть немного головой думать надо...
>>>Вы точно уверены, что CDPUserSVC — это рефакторинг кода CDPSvc,
blp>>Да.
S>Можете раскрыть источник своей уверенности?
Little birdie told me.
blp>>Не понял, какие еще приложения? Раньше был просто CDPSvc
S>Ну, я не знаю
Ну вот вы не знаете, но зачем-то какую-то чушь порете и потом просите что-то вам доказывать и детально разжевывать, объясняя, почему то чушь. Это до какой-то степени забавно, но я уже устал.
>Каким образом CDPSvc раньше взаимодействовал с десктопами пользователей?
Предлагаю самостоятельно попробовать найти ответ на этот вопрос. Это не сложно. Начните с вопроса "А взаимодействовует ли сейчас CDPUserSvc с десктопами пользователей?"
blp>>я общаюсь на уровне собеседников.
S>Не, вы лучше на своём уровне общайтесь.
На более высоком уровне имеет смысл общаться с людьми, которые
— сами хорошо разбираются в предмете
— в состоянии хорошо в нем разобраться после указания на доступные материалы
— задают интересные и оригинальные вопросы
ничего из вышеописанного не происходит, увы.
Серьезно заниматься тут просвещением ширнармасс и борьбой с религиознвым мракобесием можно только за деньги =)
S>Цитирую:
Здесь нет ничего конкретного. На последующий вопрос как именно вы будете без сервисов процессы запускать и трекать на каждый логин логофф вы ничего путного не ответили. "Сделаем как в iis " не ответ потому что в iis не надо делать per-session. А если делать один большой сервис, то это решение другой задачи, изоляции не будет.
S>Нет, не в курсе. Ну, то есть те части продукции Microsoft, которые наблюдаю лично я
О, что наблюдаете лично вы это несомненно очень важно. Может, вы смотрите на какой-нибудь адов продукт типа шарепоинта. Как это относится к разработке центральных компонентов ОС, сервисов и т д — неведомо. Автотесты на API у них какие-то. Какой API, где документирован, сколько человек его использует...
S>Если у вас есть какая-то инсайдерская инфа — делитесь, это как раз интересно.
Может и интересно, только не в коня корм. Думаю, не стоит, да и нельзя наверное.
\blp>>Это почему? Потому что вам так удобнее?
S>Нет, потому что вы выбрали аргументацию про изоляцию, а не про взаимодействие с десктопом.
Мы с самого начала обсуждаем как сделать чтобы системный код был изолирован per-user-logon-session. Срач начался с "чем это лучше чем таски или банальный авторан?"
Вы зачем-то привели нерелеватный пример iis, который просто создает w3wp процессы, никак к логон сессям не привязанные. Если бы надо было создавать несколько процессов, никак не привязаных к циклу логина — логоффа — оно было бы релеватно хоть как-то.
S>А в чём специфика проблем per-user-logon-session?
Зачем вы меня спрашиваете? Себя спросите.
> И почему надо было именно per user logon session, а не per user?
Потому что жизнь такая
>Если я, скажем, дважлы по RDP зайду на одну машину — сколько экземпляров per-user сервиса будет создано?
Зависит от многих факторов. Multiple different RDP sessions per user вполне возможны. HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" fSingleSessionPerUser -> 0 и т д
S>Хороший вопрос. А где берётся токен для per-user service?
Где же он действительно берется? Задайте себе еще более интересный вопрос — где берется токен, под которым запускаются вообще все юзерские приложения, explorer.exe там и т д. Где берется токен, используемый для per-user сервисов?
S>>>Нет, мы говорим не о шатдауне, а о logoff.
Вы просто говорите о вещах, в которых не разбираетесь.
S>Ну, на мой взгляд шатдаун радикально отличается тем
Кого волнует, чемони на ваш взгляд отличаются
S>А с логоффом-то что не так?
Логофф — это такой тип шатдауна.
> Грубо говоря, если у меня бежит обычное приложение в рамках пользовательской сессии, и ему намекают про WM_QUERYENDSESSION, то нужно по-быстрому отдать данные сервису (а это можно сделать _очень_ быстро, даже если этих данных там гигабайт), и быть готовым к WM_ENDSESSION/WM_CLOSE. Пусть пользователь себе логоффится, а записью данных будет заниматься сервис, которому пользовательская сессия не нужна.
Да, давайте опять сделаем центральный сервис вместо того, чтобы изолировать процессы разный логон-сессий. Потому что цикровая лошать умеет только бегать по кругу. Мне уже надоело по третьему разу это комментировать.
S>Вроде всё норм. А вот зачем задерживать именно логофф — тут я не понимаю. Как, впрочем, не понимаю, какими средствами это можно сделать в рамках хоть приложения, хоть сервиса.
Ну, не понимаете, так не понимаете. Что ж тут поделать. Ссылки я давал — перечитайте мои ответы со ссылками и содержимое ссылок — может, поможет, не знаю. Второй раз разжевывать я не буду. Sapienti sat.
blp>>Читать MSDN все-таки придется, если хотите разобраться.
S>Ок, где именно читать?
S>Тогда о чём вообще вы говорили в рамках идеи задержать логофф? Вы же хотите именно логофф задерживать — как это делается?
при логоффе per-user-session сервисы останавливаются, после того, как завершены все приложения, относящиеся к сессии.
Пока сервисы не остановятся, логофф не заканчивается.
Таймаут на свою остановку сервис определяет сам, и он может быть довольно большим (3 минуты по умолчанию). Если бы вы читали ссылки, что я даю, вы бы это и так знали.
>>>Напомню, что мы обсуждаем именно logoff
blp>>В windows logoff — это такой тип шатдауна, как бы странно это ни звучало. Текст по ссылке вы не читали либо читали невнимательно. Даже сам логофф можно выполнить командой shutdown /l
S>По ссылке написано, что приложение не может отличит логофф от шатдауна.
Ага. В голове ничего не щелкнуло?
S>Я по-прежнму не понимаю, почему логофф должен прибить мои системные процессы?
Потому что у вас системный процесс со временем жизни в юзерскую логон-сессию? Для изоляции, помните?
S>Почему же не надо? Я всё прочитал.
Ну значит прочитали и не поняли.
>Приложение, если ему надо, может получить ажно 30 секунд на выполнение "последней воли".
А таймаут остановки сервиса определяете самим сервисом. Улавливаете?
> Не вижу никакого смысла исполнять критический код в рамках интерактивной сессии
Ну не видите и не видите. Конечно, то, чего вы не видите, не существует.
blp>>Никаких проблем. "Все отнять и поделить" (с) Шариков.
S>Ну, в MSDN написано именно так.
Нет, в MSDN так не написано.
S>Ок, жаль. А только было началось что-то интересное.
Се ля ви.
S>Если уж вас потянуло на откровенность — расскажите, почему не стали именовать сервисы в стиле CDPUserSvc$3 — ведь их же ровно 1 на сессию, конфликта имён не будет. Зато угадывать имена сервисов стало бы проще, можно обойтись без tasklist, одним qwinsta.
Потому что LUID в имени сервиса — гарантированно уникальный на каждый логон эвент на все время, пока машину не перезагрузят, а session id может переиспользоваться в ряде случаев.
S>Ну вот мне и интересно поговорить с точки зрения того, кто архитектурит.
Да оно понятно. Все хотят говорить про архитектуру, тольку уровень "разговоров" все равно на уровне джуниоров, которым ничего архитектурить не дают.
lp>>Ну, ее придумали в результате планирования новых фич, которые нужны были бизнесу. Бизнесу нужна была изоляция процессов для большей reliability и меньшего количества крашей. Проанализировали дампы — телеметрию и приняли решение.
S>Отлично. Почему не устроила изоляция при помощи worker process, как это сделано в IIS? Почему все эти процессы надо было оформлять именно как сервисы?
Я уже это объяснял, но вы не поняли. Не "не устроила изоляция при помощи worker process" — системный код просто нельзя запихать в просто приложения, чтобы он корректно стартовал и деинициализировался при логоне-логоффе. Ваши попытки сформулировтаь, как именно это сделать, приводили пока либо
— к решению другой задачи (рисовать лошадку) — per-user стейт держать в одном процессе-сервисе, а не process per user session — прямо противоречит изоляции по процессам
— к предложению просто неработающих решений на базе приложений, которые будут "как-то" запускаться при логоне и "как-то" потом завершаться — когда были заданы детальные вопросы, вы на них не ответили.
> Ну, и по-прежнему непонятно, как это повлияет на количество крэшей.
Ну, непонятно так непонятно. Жизнь-боль и т. д.
S>Если сервис CDPSvc у пользователя Васи крэшится раз в неделю из-за бага в сервисе, то как перенос этого бага в отдельный сервис поможет что-то там сократить? Он же по-прежнему будет крэшиться раз в неделю.
Вместе с CDPSvc будут потенциально крашиться зависящие от него процессы. Не только Васи, но и у Пети, сидящем на той же машине по RDP.
После рефакторинга никто, кроме Васи зааффекчен не будет (если ситуация, приводящая к крашу, возникает в коде. который выполняется для Васи).
Ну хоть немного головой думать надо...
>>>Вы точно уверены, что CDPUserSVC — это рефакторинг кода CDPSvc,
blp>>Да.
S>Можете раскрыть источник своей уверенности?
Little birdie told me.
blp>>Не понял, какие еще приложения? Раньше был просто CDPSvc
S>Ну, я не знаю
Ну вот вы не знаете, но зачем-то какую-то чушь порете и потом просите что-то вам доказывать и детально разжевывать, объясняя, почему то чушь. Это до какой-то степени забавно, но я уже устал.
>Каким образом CDPSvc раньше взаимодействовал с десктопами пользователей?
Предлагаю самостоятельно попробовать найти ответ на этот вопрос. Это не сложно. Начните с вопроса "А взаимодействовует ли сейчас CDPUserSvc с десктопами пользователей?"
blp>>я общаюсь на уровне собеседников.
S>Не, вы лучше на своём уровне общайтесь.
На более высоком уровне имеет смысл общаться с людьми, которые
— сами хорошо разбираются в предмете
— в состоянии хорошо в нем разобраться после указания на доступные материалы
— задают интересные и оригинальные вопросы
ничего из вышеописанного не происходит, увы.
Серьезно заниматься тут просвещением ширнармасс и борьбой с религиознвым мракобесием можно только за деньги =)
S>Цитирую:
Здесь нет ничего конкретного. На последующий вопрос как именно вы будете без сервисов процессы запускать и трекать на каждый логин логофф вы ничего путного не ответили. "Сделаем как в iis " не ответ потому что в iis не надо делать per-session. А если делать один большой сервис, то это решение другой задачи, изоляции не будет.
S>Нет, не в курсе. Ну, то есть те части продукции Microsoft, которые наблюдаю лично я
О, что наблюдаете лично вы это несомненно очень важно. Может, вы смотрите на какой-нибудь адов продукт типа шарепоинта. Как это относится к разработке центральных компонентов ОС, сервисов и т д — неведомо. Автотесты на API у них какие-то. Какой API, где документирован, сколько человек его использует...
S>Если у вас есть какая-то инсайдерская инфа — делитесь, это как раз интересно.
Может и интересно, только не в коня корм. Думаю, не стоит, да и нельзя наверное.
\blp>>Это почему? Потому что вам так удобнее?
S>Нет, потому что вы выбрали аргументацию про изоляцию, а не про взаимодействие с десктопом.
Мы с самого начала обсуждаем как сделать чтобы системный код был изолирован per-user-logon-session. Срач начался с "чем это лучше чем таски или банальный авторан?"
Вы зачем-то привели нерелеватный пример iis, который просто создает w3wp процессы, никак к логон сессям не привязанные. Если бы надо было создавать несколько процессов, никак не привязаных к циклу логина — логоффа — оно было бы релеватно хоть как-то.
S>А в чём специфика проблем per-user-logon-session?
Зачем вы меня спрашиваете? Себя спросите.
> И почему надо было именно per user logon session, а не per user?
Потому что жизнь такая
>Если я, скажем, дважлы по RDP зайду на одну машину — сколько экземпляров per-user сервиса будет создано?
Зависит от многих факторов. Multiple different RDP sessions per user вполне возможны. HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" fSingleSessionPerUser -> 0 и т д
S>Хороший вопрос. А где берётся токен для per-user service?
Где же он действительно берется? Задайте себе еще более интересный вопрос — где берется токен, под которым запускаются вообще все юзерские приложения, explorer.exe там и т д. Где берется токен, используемый для per-user сервисов?
S>>>Нет, мы говорим не о шатдауне, а о logoff.
Вы просто говорите о вещах, в которых не разбираетесь.
S>Ну, на мой взгляд шатдаун радикально отличается тем
Кого волнует, чемони на ваш взгляд отличаются
S>А с логоффом-то что не так?
Логофф — это такой тип шатдауна.
> Грубо говоря, если у меня бежит обычное приложение в рамках пользовательской сессии, и ему намекают про WM_QUERYENDSESSION, то нужно по-быстрому отдать данные сервису (а это можно сделать _очень_ быстро, даже если этих данных там гигабайт), и быть готовым к WM_ENDSESSION/WM_CLOSE. Пусть пользователь себе логоффится, а записью данных будет заниматься сервис, которому пользовательская сессия не нужна.
Да, давайте опять сделаем центральный сервис вместо того, чтобы изолировать процессы разный логон-сессий. Потому что цикровая лошать умеет только бегать по кругу. Мне уже надоело по третьему разу это комментировать.
S>Вроде всё норм. А вот зачем задерживать именно логофф — тут я не понимаю. Как, впрочем, не понимаю, какими средствами это можно сделать в рамках хоть приложения, хоть сервиса.
Ну, не понимаете, так не понимаете. Что ж тут поделать. Ссылки я давал — перечитайте мои ответы со ссылками и содержимое ссылок — может, поможет, не знаю. Второй раз разжевывать я не буду. Sapienti sat.
blp>>Читать MSDN все-таки придется, если хотите разобраться.
S>Ок, где именно читать?
S>Тогда о чём вообще вы говорили в рамках идеи задержать логофф? Вы же хотите именно логофф задерживать — как это делается?
при логоффе per-user-session сервисы останавливаются, после того, как завершены все приложения, относящиеся к сессии.
Пока сервисы не остановятся, логофф не заканчивается.
Таймаут на свою остановку сервис определяет сам, и он может быть довольно большим (3 минуты по умолчанию). Если бы вы читали ссылки, что я даю, вы бы это и так знали.
>>>Напомню, что мы обсуждаем именно logoff
blp>>В windows logoff — это такой тип шатдауна, как бы странно это ни звучало. Текст по ссылке вы не читали либо читали невнимательно. Даже сам логофф можно выполнить командой shutdown /l
S>По ссылке написано, что приложение не может отличит логофф от шатдауна.
Ага. В голове ничего не щелкнуло?
S>Я по-прежнму не понимаю, почему логофф должен прибить мои системные процессы?
Потому что у вас системный процесс со временем жизни в юзерскую логон-сессию? Для изоляции, помните?
S>Почему же не надо? Я всё прочитал.
Ну значит прочитали и не поняли.
>Приложение, если ему надо, может получить ажно 30 секунд на выполнение "последней воли".
А таймаут остановки сервиса определяете самим сервисом. Улавливаете?
> Не вижу никакого смысла исполнять критический код в рамках интерактивной сессии
Ну не видите и не видите. Конечно, то, чего вы не видите, не существует.
blp>>Никаких проблем. "Все отнять и поделить" (с) Шариков.
S>Ну, в MSDN написано именно так
.Нет, в MSDN так не написано.
S>Ок, жаль. А только было началось что-то интересное.
Се ля ви.
S>Если уж вас потянуло на откровенность — расскажите, почему не стали именовать сервисы в стиле CDPUserSvc$3 — ведь их же ровно 1 на сессию, конфликта имён не будет. Зато угадывать имена сервисов стало бы проще, можно обойтись без tasklist, одним qwinsta.
Потому что LUID в имени сервиса — гарантированно уникальный на каждый логон эвент на все время, пока машину не перезагрузят, а session id может переиспользоваться в ряде случаев.