Ну опишите универсальный способ для многопоточной обработки событий. Мой способ влазит в несколько строк (я не учитываю тут правильную обработку потоков, у меня она неправильная, но я и не ставил цель сделать ее правильной)
А зачем? Он ведь уже есть. Я ведь сказал, что в большинстве случаев будет достаточно этого. Но я не видел пока живых примеров, где не хватало бы EventHandler
События и обсерверы имеют разные области применения. Использовать паттерн «наблюдатель», на мой взгляд, имеет смысл, когда генератору событий нужно знать, кто ожидает оповещений и/или выбирать, кому отправить данное оповещение, а кому нет. Мне вот сбербанк отправляет информацию о моих операциях, а вам о моих не отправляет… зато отправляет о ваших… Вот хороший пример обсервера.
Так вот, без знания ответов на эти вопросы ваша идея опасна.
Идея тут не может быть опасна. Опасна реализация. Но я же предупредил, что все примеры чисто тестовые. Я тут рассматриваю абстрактного коня в вакууме. Вот если бы я написал библиотеку и выложил на гитхаб, то данное замечание было бы уместно.
Так что же будет, если обработчик не обработает ошибку, и она из него вылетит?
Тут все зависит от того, пытается ли обработчик лезть в другие потоки. Если он тихонечко работает в своем конткесте, то с больше долей вероятности он просто упадет и никому об этом не расскажет :)
Если вам все таки хочется об этом узнать, оборачивайте операции обработчика в try catch
Ну хорошо, а если надо больше аргументов события? В этом случае вам придется либо на каждое количество аргументов писать отдельный дженерик метод, либо делать свою собственную реализацию EventArgs, но зачем, если она уже есть?
Я уже ответил на прошлый коммент по этому поводу. Пул потоков не относится к теме данной статьи. Вы можете рулить задачами с шелдером… да чем угодно. Я только предложил идею, как универсализировать систему событий и объяснил где и как работают обработчики
Круто, а теперь ответьте на свой же вопрос: в каком потоке выполняется событие?
Тут из-за нечеткой терминологии могут возникнуть непонятки у нас. Событие не выполняется, оно генерируется. Ну или как то так. А выполняются обработчики. Так вот в моем примере каждый обработчик выполняется в отдельном потоке.
Вот, значит, кто-то подписал на ваше событие две сотни обработчиков. Сколько будет потоков? Откуда они возьмутся? А откуда они возьмутся при втором вызове того же события?
Я на старте еще написал, что речь тут не про потоки, а про события в контексте потоков. Я тут не занимался разруливанием потоков. Если вам необходимо рулить пулом, шелдером или еще чем, поищите информацию сами. Я лишь дал идею.
Агу. А что будет, если в обработчике возникнет ошибка (exception кто-то бросит)?
Во-первых, в моем примере генератора событий вообще не волнует как это событие будет обработано. поэтому, если возникнет ошибка, то обрабатывать ее надо в методе-обработчике. В случае моего примера это
Я в курсе, что есть такой функционал. Нужно это для ожидания завершения и получения результата. Но ИвентХандлеры возвращают void. Поэтому, если дожидаться выполнения работы обработчика нам не нужно, использовать EndInvoke незачем.
Если я чего то не знаю, расскажите, я сам не так давно начал копать систему работы событий и буду рад любым замечаниям.
Я ведь в конце об этом написал. Смотрите на класс AsyncEventsHelper. Такой фокус бы не удался при использовании Action или MyDelegate. А в большинстве случаев (по моим личным наблюдениям) данный способ оповещения вполне подходит.
Считайте это упрощением работы событий для частного случая. Но дело в том, что этот частный случай встречается чаще других при разработке.
Так котиков и бань. Если, конечно, статья не будет повествовать о том, как кот может пригодится гику в хозяйстве. Например, как научить приносить его пиво :)
Если не делать «самую идеальную игру», то платформа чата вполне удобна. Во первых, тебе, как пользователю, не нужно ничего устанавливать.
Ну а как разработчику, тебе не придется париться передачей данных, и еще многими моментами, за тебя уже все придумали.
да, вычистит. Для этого ею надо делать движения от десны к концу зуба. А если ты ее прижимаешь… вон посмотри на картинку в статье что происходит. Я ее не сам придумал.
Идея тут не может быть опасна. Опасна реализация. Но я же предупредил, что все примеры чисто тестовые. Я тут рассматриваю абстрактного коня в вакууме. Вот если бы я написал библиотеку и выложил на гитхаб, то данное замечание было бы уместно.
Тут все зависит от того, пытается ли обработчик лезть в другие потоки. Если он тихонечко работает в своем конткесте, то с больше долей вероятности он просто упадет и никому об этом не расскажет :)
Если вам все таки хочется об этом узнать, оборачивайте операции обработчика в try catch
Тут из-за нечеткой терминологии могут возникнуть непонятки у нас. Событие не выполняется, оно генерируется. Ну или как то так. А выполняются обработчики. Так вот в моем примере каждый обработчик выполняется в отдельном потоке.
Я на старте еще написал, что речь тут не про потоки, а про события в контексте потоков. Я тут не занимался разруливанием потоков. Если вам необходимо рулить пулом, шелдером или еще чем, поищите информацию сами. Я лишь дал идею.
Во-первых, в моем примере генератора событий вообще не волнует как это событие будет обработано. поэтому, если возникнет ошибка, то обрабатывать ее надо в методе-обработчике. В случае моего примера это
Если я чего то не знаю, расскажите, я сам не так давно начал копать систему работы событий и буду рад любым замечаниям.
Считайте это упрощением работы событий для частного случая. Но дело в том, что этот частный случай встречается чаще других при разработке.
Ну а как разработчику, тебе не придется париться передачей данных, и еще многими моментами, за тебя уже все придумали.