Здравствуйте, те кто работал, работает с SP, знаете ли вы о том, как работает данный класс? (SP2010)
Аналогичен ли он описанному у рихтера ThreadPool'у?
PS
Описание на MSDN опять оставляет желать лучшего.
Здравствуйте, -n1l-, Вы писали:
N>Здравствуйте, те кто работал, работает с SP, знаете ли вы о том, как работает данный класс? (SP2010) N>Аналогичен ли он описанному у рихтера ThreadPool'у?
Класс не использовал, посмотрел декомпилером.
SPThreadPool — это два вспомогательных метода (QueueUserWorkItemWithImpersonation(WaitCallback callback, object state) и QueueUserWorkItemWithUserToken(WaitCallback callback, object state, SPUserToken token)), которые внутри дергают все тот же ThreadPool.QueueUserWorkItem. Задача обоих методов — обеспечить выполнение callback'а под учеткой определенного пользователя. Для этого перед тем как дернуть callback выполняется либо SPSecurity.RunAsUser, либо Identity.Impersonate, либо callback дергается под дефолтной учеткой потока.
Есть там еще парочка internal методов (RunAsyncWorkItemWithImpersonation и RunAsyncWorkItemWithUserToken). Они сводятся к вызову BeginInvoke того же промежуточного метода, что и для QueueUserWorkItem*, который прежде чем дернуть callback выполняет настройку учетной записи потока.
Так что SPThreadPool — это всего лишь helper'ы, настраивающие контекст выполнения задачи.
Здравствуйте, /Forester/, Вы писали: F>Класс не использовал, посмотрел декомпилером.
Спасибо за ответ. Тоже смотрел, смутила эта учетка.
Непонимаю, если вызывать ее безотносительно учетки, что тогда будет.
Например вызывать метод QueueUserWorkItemWithImpersonation на каком-нибудь эвентресивере.
Он сломается? Или нет. Эх придется экспериментировать.
Здравствуйте, -n1l-, Вы писали:
N>Например вызывать метод QueueUserWorkItemWithImpersonation на каком-нибудь эвентресивере. N>Он сломается? Или нет. Эх придется экспериментировать.
Здравствуйте, gandjustas, Вы писали:
G>Фоновая обработка чего? Быстрота обработки чего?
Определенных данных. Сложная логика, просто так не объяснить. G>Вообще в веб-приложениях вредно запускать что-то параллельно, ибо это начинает кушать потоки, которые нужны для обработки запросов.
Посему использую ThreadPool, добавляя в очередь.
Здравствуйте, -n1l-, Вы писали:
N>Здравствуйте, gandjustas, Вы писали:
G>>Фоновая обработка чего? Быстрота обработки чего? N>Определенных данных. Сложная логика, просто так не объяснить.
А данные откуда берутся? Есть подозрение, что основное время "обработки" — запросы, а их лучше не параллелить через Thread Pool, это убъет производительность фронтэнда.
G>>Вообще в веб-приложениях вредно запускать что-то параллельно, ибо это начинает кушать потоки, которые нужны для обработки запросов. N>Посему использую ThreadPool, добавляя в очередь.
ASP.NET использует тот же пул если что, и ты ему мешаешь. А в случае шарика (который и так медленный) мешать ему нельзя, вообще неюзабельным станет.
Здравствуйте, gandjustas, Вы писали:
G>А данные откуда берутся? Есть подозрение, что основное время "обработки" — запросы, а их лучше не параллелить через Thread Pool, это убъет производительность фронтэнда.
Данные берутся из итема одного списка. Список недоступен для пользователей, вообще вся функциональность ui-шарика для пользователей недоступна, доступны только определенные страницы. Так вот на список повешен хендлер, при добавлении нового итема в этот список начинается его парсинг и затем обработка. Затем либо удаление, если все хорошо, либо либо он остается в списке если произошла ошибка в обработке и содержит инфу об ошибке.
Юзеры с этим списком не работают.
G>ASP.NET использует тот же пул если что, и ты ему мешаешь. А в случае шарика (который и так медленный) мешать ему нельзя, вообще неюзабельным станет.
Так то везде тот же пул, системный, другого нет.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, -n1l-, Вы писали:
G>>>Фоновая обработка чего? Быстрота обработки чего? N>>Определенных данных. Сложная логика, просто так не объяснить.
AVK>Сложную логику лучше вынести в отдельный сервис, а не насиловать веб-сервер. Ну и UI соответственно организовать через какой нибудь Signal/R.
Поясните пожалуйста. Вы предлагаете использовать wcf?
Здравствуйте, -n1l-, Вы писали:
N>Здравствуйте, gandjustas, Вы писали:
G>>А данные откуда берутся? Есть подозрение, что основное время "обработки" — запросы, а их лучше не параллелить через Thread Pool, это убъет производительность фронтэнда. N>Данные берутся из итема одного списка. Список недоступен для пользователей, вообще вся функциональность ui-шарика для пользователей недоступна, доступны только определенные страницы. Так вот на список повешен хендлер, при добавлении нового итема в этот список начинается его парсинг и затем обработка. Затем либо удаление, если все хорошо, либо либо он остается в списке если произошла ошибка в обработке и содержит инфу об ошибке. N>Юзеры с этим списком не работают.
Тогда зачем Thread Pool? Для асинхронного post-ресивера и так отдельный поток запускается. Так как задача вполняется в фоне, то запускать несколько потоков вообще вредно, фоновые задачи должны кушать минимум ресурсов.
Здравствуйте, -n1l-, Вы писали:
AVK>>Сложную логику лучше вынести в отдельный сервис, а не насиловать веб-сервер. Ну и UI соответственно организовать через какой нибудь Signal/R. N>Поясните пожалуйста. Вы предлагаете использовать wcf?
По желанию. WCF — неплохой выбор. Но можно и WebAPI + Signal/R для нотификаций.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, gandjustas, Вы писали:
G>Тогда зачем Thread Pool? Для асинхронного post-ресивера и так отдельный поток запускается. Так как задача вполняется в фоне, то запускать несколько потоков вообще вредно, фоновые задачи должны кушать минимум ресурсов.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, -n1l-, Вы писали:
G>>>Фоновая обработка чего? Быстрота обработки чего? N>>Определенных данных. Сложная логика, просто так не объяснить.
AVK>Сложную логику лучше вынести в отдельный сервис, а не насиловать веб-сервер. Ну и UI соответственно организовать через какой нибудь Signal/R.
Написанное коррелирует с sharepoint чуть менее, чем никак.
Здравствуйте, -n1l-, Вы писали:
AVK>>По желанию. WCF — неплохой выбор. Но можно и WebAPI + Signal/R для нотификаций. N>Подробнее можете объяснить свою идею?
Что именно в идее непонятно?
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
