Re[3]: Как корректно остановить асинхронное чтение из UdpCli
От: merk Россия  
Дата: 23.07.08 13:46
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, merk, Вы писали:


>> колбеку нежелательно управлять самим собой.

А>Я собираюсь попробовать следующую схему. DataReceiver.Start запускает поток, который крутится в цикле, запуская асинхронную операцию получения дейтаграммы и ожидая ее завершения или сигнала к остановке. Callback вообще не используется.
если там есть и такой безколбековый способ, то он вполне правомерен. скорее всего это делается через скрытый колбек, врапированный. но эсли это проще, то чем проще тем лучше.

>> еще хуже блокировки в колбеке за счет вызова каких то ваших "передач данных подписчикам"

А>С этим как раз проблем нет — я генерирую event, подписчик которого добавляет пакте в очередь (producer / consumer), задержка минимальна. То, что подписчик обязан обеспечить минимальную задержку, документировано в интерфейсе класса.
это правильно. но я в таких случах, также проверяю таки, что подписчик обеспечивает этот контракт. что делается проверкой на реентер. в реальности может быть ситуация что подписчик контракт хотел бы обеспечить, но не может. например пошла сборка мусора, если это .net, или очередь eventoв у вас переполняется. тогда если не проверять система просто застрянет. а если проверять — будет ругаться в лог, что подписчик тормозит и все такое.

А>Спасибо за ответ. Подумав над вопросами и перечитав Asynchronous Programming Design Patterns, решил отказаться от callback. Асинхронность по-прежнему нужна, чтобы можно было завершить работу DataReceiver во время ожидания очередного пакета (или если пакетов вообще нет).

асинхронность нужна по любому, поскольку данные к вам приходят вне засимости от вашего желания. а принципиальные вещи не устранишь никакими трюками.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.