Как правильно использовать Eventы в Thread ?
Например в таком коде

Проблема возникает если в обработчике eventa происходит исключение или зависание, это нарушает работу потока, а по идее он должен работать не зависимо от работоспособности подписчиков. От эксепшенов еще можно спастись обернув вызов в try catch., а вот от зависонов не совсем понятно как.

public class Test
{
   public void static ThreadFunc()
   {
       public event SomeHandler OnDoSomethingEnd

        while( true )
        {
            DoSomethingLong();

            if ( OnDoSomethingEnd != null )
                 OnDoSomethingEnd( someparams );
        }
   }
}

Здравствуйте, Аноним, Вы писали:

А>Как правильно использовать Eventы в Thread ?
А>Например в таком коде

А>Проблема возникает если в обработчике eventa происходит исключение или зависание, это нарушает работу потока, а по идее он должен работать не зависимо от работоспособности подписчиков. От эксепшенов еще можно спастись обернув вызов в try catch., а вот от зависонов не совсем понятно как.

А>

А>public class Test
А>{
А>   public void static ThreadFunc()
А>   {
А>       public event SomeHandler OnDoSomethingEnd

А>        while( true )
А>        {
А>            DoSomethingLong();

А>            if ( OnDoSomethingEnd != null )
А>                 OnDoSomethingEnd( someparams );
А>        }
А>   }
А>}
А>

public class Test
{
   public void static ThreadFunc()
   {
       public event SomeHandler OnDoSomethingEnd

        while( true )
        {
            DoSomethingLong();

            if ( OnDoSomethingEnd != null )
            {
               foreach( SomeHandler hnd in OnDoSomethingEnd.GetInvocationList() )
               {
                  hnd.BeginInvoke(someparams);
               }
            }
        }
   }
}

Здравствуйте, Аноним, Вы писали:

А>Проблема возникает если в обработчике eventa происходит исключение или зависание, это нарушает работу потока, а по идее он должен работать не зависимо от работоспособности подписчиков. От эксепшенов еще можно спастись обернув вызов в try catch., а вот от зависонов не совсем понятно как.

А какое поведение по-вашему должно быть в случае зависшего handler-а?
Можно конечно его стартовать в отдельном потоке, но в итоге мы быстро очень быстро упремся в ограничение по памяти.

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

L>А какое поведение по-вашему должно быть в случае зависшего handler-а?
L>Можно конечно его стартовать в отдельном потоке, но в итоге мы быстро очень быстро упремся в ограничение по памяти.

Зависший убивать Abort-ом.

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


L>>А какое поведение по-вашему должно быть в случае зависшего handler-а?
L>>Можно конечно его стартовать в отдельном потоке, но в итоге мы быстро очень быстро упремся в ограничение по памяти.

___>Зависший убивать Abort-ом.

А как отличить зависший от долго-работающего? Не говоря уж о том, что Abort — это не кошерно.

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

___>>Зависший убивать Abort-ом.

L>А как отличить зависший от долго-работающего? Не говоря уж о том, что Abort — это не кошерно.

Это вопрос к автору топика.

Здравствуйте, Аноним, Вы писали:

А>Как правильно использовать Eventы в Thread ?
А>Например в таком коде

А>Проблема возникает если в обработчике eventa происходит исключение или зависание, это нарушает работу потока, а по идее он должен работать не зависимо от работоспособности подписчиков. От эксепшенов еще можно спастись обернув вызов в try catch., а вот от зависонов не совсем понятно как.

А зачем избавляться "от зависонов" Если они в принципе есть, то рано или поздно зависнет каждый имеющийся у вас поток.

Если вы боитесь, что подписчики могут "зависнуть" и нарушить работу вашего кода, организуйте работу с ними по-другому: публикуйте данные о событии в некоторой очереди и пускай подписчики сами читают из неё. Только тогда их "зависоны" не будут вас беспокоить.

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

L>>А как отличить зависший от долго-работающего? Не говоря уж о том, что Abort — это не кошерно.

___>Это вопрос к автору топика.

Да нет, именно к тебе. Технически зависший поток ничем не отличается от долгоработающего.

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

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

L>>>А как отличить зависший от долго-работающего? Не говоря уж о том, что Abort — это не кошерно.

___>>Это вопрос к автору топика.

L>Да нет, именно к тебе. Технически зависший поток ничем не отличается от долгоработающего.

Нет к автору. Я ж не знаю что у него там за "зависшие потоки".

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

L>>А какое поведение по-вашему должно быть в случае зависшего handler-а?
L>>Можно конечно его стартовать в отдельном потоке, но в итоге мы быстро очень быстро упремся в ограничение по памяти.

___>Зависший убивать Abort-ом.

Это очень плохой способ, тем более, когда не известно, чем занимается убиваемый поток: например, если он внутри себя создаёт Excel.Application и "зависает" в процессе работы с ним, то при убивании потока сервер Excel.exe так и останется запущенным. Через какое-то время подобной "работы" процессов экселя может быть создано не мало, что может помешать работе системы в целом.

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

L>>Да нет, именно к тебе. Технически зависший поток ничем не отличается от долгоработающего.

___>Нет к автору. Я ж не знаю что у него там за "зависшие потоки".

Раз ты предлагаешь использовать Abort для зависших, то это автоматически означает, что ты знаешь, что такое зависший поток.

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

___>>Нет к автору. Я ж не знаю что у него там за "зависшие потоки".

L>Раз ты предлагаешь использовать Abort для зависших, то это автоматически означает, что ты знаешь, что такое зависший поток.

И с чем же мы не сгласны, _FRED_?

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

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

L>>>Да нет, именно к тебе. Технически зависший поток ничем не отличается от долгоработающего.

___>>Нет к автору. Я ж не знаю что у него там за "зависшие потоки".

L>Раз ты предлагаешь использовать Abort для зависших, то это автоматически означает, что ты знаешь, что такое зависший поток.

Да знаю: зависший поток, это поток который deadlocked и не может быть убит другими методами кроме Abort.

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

___>>>Нет к автору. Я ж не знаю что у него там за "зависшие потоки".

L>>Раз ты предлагаешь использовать Abort для зависших, то это автоматически означает, что ты знаешь, что такое зависший поток.

___>Да знаю: зависший поток, это поток который deadlocked и не может быть убит другими методами кроме Abort.

Это определение практической ценности практически не несет: мы не можем определить, что процесс именно deadlocked и следовательно когда надо использовать Abort.

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

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

___>>>>Нет к автору. Я ж не знаю что у него там за "зависшие потоки".

L>>>Раз ты предлагаешь использовать Abort для зависших, то это автоматически означает, что ты знаешь, что такое зависший поток.

___>>Да знаю: зависший поток, это поток который deadlocked и не может быть убит другими методами кроме Abort.

L>Это определение практической ценности практически не несет: мы не можем определить, что процесс именно deadlocked и следовательно когда надо использовать Abort.

Какой еще нафиг процесс? Кто пишет процедуру потока? Может ты доколупаешься до автора топика?

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

L>>Это определение практической ценности практически не несет: мы не можем определить, что процесс именно deadlocked и следовательно когда надо использовать Abort.

___>Какой еще нафиг процесс?

Сорри, поток.

___>Кто пишет процедуру потока?

Я не знаю, об этом в постановке не говорится.

___>Может ты доколупаешься до автора топика?

Зачем? Я же обсуждаю предложенное тобой решение, а не вопрос.

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

_FR>Здравствуйте, Аноним, Вы писали:

А>>Как правильно использовать Eventы в Thread ?
А>>Например в таком коде

А>>Проблема возникает если в обработчике eventa происходит исключение или зависание, это нарушает работу потока, а по идее он должен работать не зависимо от работоспособности подписчиков. От эксепшенов еще можно спастись обернув вызов в try catch., а вот от зависонов не совсем понятно как.

_FR>А зачем избавляться "от зависонов" Если они в принципе есть, то рано или поздно зависнет каждый имеющийся у вас поток.

_FR>Если вы боитесь, что подписчики могут "зависнуть" и нарушить работу вашего кода, организуйте работу с ними по-другому: публикуйте данные о событии в некоторой очереди и пускай подписчики сами читают из неё. Только тогда их "зависоны" не будут вас беспокоить.

Да , второй вариант, а то что будет виснуть рабочий поток — это его проблемы и надо фиксить.
А вот если рабочий поток отлажен и подписчики вроде бы стабильно работают, то подключение к event одного "неудачника" не должно приводить к катастрофе и влиянию на работу тех кто работает корректно.

А чем плохо предложенное выше решение _d_m_ с BeginInvoke, я пока не тестировал, но подозреваю что это что-то на подобии асинхронного вызова.
http://www.rsdn.ru/forum/dotnet/4058443.1.aspx

Автор: _d_m_
Дата: 30.11.10

Здравствуйте, Аноним, Вы писали:

А>А вот если рабочий поток отлажен и подписчики вроде бы стабильно работают, то подключение к event одного "неудачника" не должно приводить к катастрофе и влиянию на работу тех кто работает корректно.

Если вам достаточно таких гарантий — делайте как хотите. Но, обычно, надёжность системы определяется надёжностью самого слабого звена, а не отношением количества надёжных к количеству слабых. Поэтому надёжность повышается не увеличением количества стабильных звеньев, а устранением наислабейших.

А>А чем плохо предложенное выше решение _d_m_ с BeginInvoke, я пока не тестировал, но подозреваю что это что-то на подобии асинхронного вызова.
А>http://www.rsdn.ru/forum/dotnet/4058443.1.aspx

Автор: _d_m_
Дата: 30.11.10

Тем, что "зависшие" потоки так и останутся висеть, занимая и занимая пул. Если вы не считаете дорогим подарить один серверный поток одному "зависшему" клиенту — сделайте так. Но почитайте, что происходит при вызове Delegate::BeginInvoke и что за потоки (откуда они берутся) будут "дариться" клиентам. Не будет ли это дорогогим ресурсом для вас?

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

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


L>>>А какое поведение по-вашему должно быть в случае зависшего handler-а?
L>>>Можно конечно его стартовать в отдельном потоке, но в итоге мы быстро очень быстро упремся в ограничение по памяти.

___>>Зависший убивать Abort-ом.

L>А как отличить зависший от долго-работающего? Не говоря уж о том, что Abort — это не кошерно.

а как taskManager в винде определяет, что надо писать "процесс не отвечает"?

Здравствуйте, Аноним, Вы писали:

L>>А как отличить зависший от долго-работающего? Не говоря уж о том, что Abort — это не кошерно.

А>а как taskManager в винде определяет, что надо писать "процесс не отвечает"?

Я могу только предположить, как он работает для виндовых программ. Для консольных — не ясно.

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

L>Здравствуйте, Аноним, Вы писали:

L>>>А как отличить зависший от долго-работающего? Не говоря уж о том, что Abort — это не кошерно.

А>>а как taskManager в винде определяет, что надо писать "процесс не отвечает"?

L>Я могу только предположить, как он работает для виндовых программ. Для консольных — не ясно.

а я про виндовые и спрашиваю? таскменеджер в винде — разве не виндовое?

Здравствуйте, Аноним, Вы писали:

L>>Я могу только предположить, как он работает для виндовых программ. Для консольных — не ясно.

А>а я про виндовые и спрашиваю? таскменеджер в винде — разве не виндовое?

Я имел в виду оконные приложения.

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

L>Здравствуйте, Аноним, Вы писали:

L>>>Я могу только предположить, как он работает для виндовых программ. Для консольных — не ясно.

А>>а я про виндовые и спрашиваю? таскменеджер в винде — разве не виндовое?

L>Я имел в виду оконные приложения.

так изначальный мой вопрос "а как taskManager в винде определяет, что надо писать "процесс не отвечает"?"
был связан с твоим вопросом
L>А как отличить зависший от долго-работающего?

это я к тому, что как-то же винда определяет завис процесс или долго работает

Здравствуйте, Аноним, Вы писали:

А>это я к тому, что как-то же винда определяет завис процесс или долго работает

Она и для консольных определяет?

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

L>Здравствуйте, Аноним, Вы писали:

А>>это я к тому, что как-то же винда определяет завис процесс или долго работает

L>Она и для консольных определяет?

не понял связи консольности приложения и "что как-то же винда определяет завис процесс или долго работает"

Здравствуйте, Аноним, Вы писали:

А>>>это я к тому, что как-то же винда определяет завис процесс или долго работает

L>>Она и для консольных определяет?

А>не понял связи консольности приложения и "что как-то же винда определяет завис процесс или долго работает"

Я могу предположить как винда это определяет для оконных приложений, но нет никаких идей, как это можно сделать для консольных.
Поэтому и возник вопрос, определяет ли винда зависшие консольные приложения?

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

L>Здравствуйте, Аноним, Вы писали:

А>>>>это я к тому, что как-то же винда определяет завис процесс или долго работает

L>>>Она и для консольных определяет?

А>>не понял связи консольности приложения и "что как-то же винда определяет завис процесс или долго работает"

L>Я могу предположить как винда это определяет для оконных приложений, но нет никаких идей, как это можно сделать для консольных.
L>Поэтому и возник вопрос, определяет ли винда зависшие консольные приложения?

ну т.е. получается что если у ТС оконное приложение, то определить таки можно: завис процесс или долго работает

Здравствуйте, Аноним, Вы писали:

А>>>не понял связи консольности приложения и "что как-то же винда определяет завис процесс или долго работает"

L>>Я могу предположить как винда это определяет для оконных приложений, но нет никаких идей, как это можно сделать для консольных.
L>>Поэтому и возник вопрос, определяет ли винда зависшие консольные приложения?

А>ну т.е. получается что если у ТС оконное приложение, то определить таки можно: завис процесс или долго работает

Нет, не получается. Единственный вывод, который можно сделать из написанного, что винда по каким-то характеристикам относит процесс к зависшим. При этом такой процесс может повисеть-повисеть и через какое-то время "отвиснуть", т.е. на самом деле он и не висел, а просто тормозил.
Короче, в конечном итоге все зависит от того, как мы определим понятие зависшего приложения. Тут предлагали относить к зависшим приложения, вставшие на deadlok-е. Не уверен, что это единственно возможное определение.

Здравствуйте, Аноним, Вы писали:

А>ну т.е. получается что если у ТС оконное приложение, то определить таки можно: завис процесс или долго работает

Диспетрчер использует функцию IsHungAppWindow. Она проверяет, обращается-ли поток окна к своей очереди сообщений. Если в течении 5 секунд такого обращения нет, то поток считается зависшим, о чём диспетчер и извещает. В W9x была какая-то другая (по имени), но с таким-же функционалом. Так-же можно использовать SendMessageTimeout c WM_NULL.

Разумеется, критерий достаточно условный, но других просто нет. И если в потоке нет окна, то отличить полезную работу от зацикливания невозможно даже теоретически. Можно конечно вставить в поток счётчик по принципу watchdog'a, но лучше просто не такого допускать.

Здравствуйте, Jolly Roger, Вы писали:

JR>Здравствуйте, Аноним, Вы писали:

А>>ну т.е. получается что если у ТС оконное приложение, то определить таки можно: завис процесс или долго работает

JR>Диспетрчер использует функцию IsHungAppWindow. Она проверяет, обращается-ли поток окна к своей очереди сообщений. Если в течении 5 секунд такого обращения нет, то поток считается зависшим, о чём диспетчер и извещает.

ну т.е. получается, что если у меня поток в процессе с низшим приоритетом и он в течение 5 секунд не может дождаться, когда ему выделиться квант времени, то он будет зависший?


JR>И если в потоке нет окна, то отличить полезную работу от зацикливания невозможно даже теоретически.

а, кстати, просвятите в чем разница оконного приложения от консольного?

Здравствуйте, Аноним, Вы писали:

А>ну т.е. получается, что если у меня поток в процессе с низшим приоритетом и он в течение 5 секунд не может дождаться, когда ему выделиться квант времени, то он будет зависший?

Да.

А>а, кстати, просвятите в чем разница оконного приложения от консольного?

У консольного в образе флаг SUSYSTEM установлен в CONSOLE. У неконсольного он иной, WINDOWS например. За подробностями пожалте в MSDN, ибо слишком много.

Здравствуйте, Jolly Roger, Вы писали:

JR>Диспетрчер использует функцию IsHungAppWindow. Она проверяет, обращается-ли поток окна к своей очереди сообщений. Если в течении 5 секунд такого обращения нет, то поток считается зависшим, о чём диспетчер и извещает. В W9x была какая-то другая (по имени), но с таким-же функционалом. Так-же можно использовать SendMessageTimeout c WM_NULL.

Если играть в буквалиста, то берётся значение из HKCU\Control Panel\Desktop\HungAppTimeout или 5 сек, если иное не указано.

L>>А как отличить зависший от долго-работающего? Не говоря уж о том, что Abort — это не кошерно.

А>а как taskManager в винде определяет, что надо писать "процесс не отвечает"?

Тупо она определяет. И безсмыссленно. Как именно — тут уже лучше меня написали, а на практике — каждый более-менее умелый автор зависшего кода делает его в отдельном потоке, GUI не замирает, винда считает, что зависания нет. В итоге — вечно бегающий progressbar.

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

А>>Проблема возникает если в обработчике eventa происходит исключение или зависание, это нарушает работу потока, а по идее он должен работать не зависимо от работоспособности подписчиков. От эксепшенов еще можно спастись обернув вызов в try catch., а вот от зависонов не совсем понятно как.

_FR>А зачем избавляться "от зависонов" Если они в принципе есть, то рано или поздно зависнет каждый имеющийся у вас поток.

_FR>Если вы боитесь, что подписчики могут "зависнуть" и нарушить работу вашего кода, организуйте работу с ними по-другому: публикуйте данные о событии в некоторой очереди и пускай подписчики сами читают из неё. Только тогда их "зависоны" не будут вас беспокоить.

Тогда будет организован пул подписчиков, который все равно придется чистить от зависших подписчиков. И убивать их потоки. Оно, конечно, лучше, но в итоге все равно приходим к .Abort() или .Interrupt(). А если они еще и loop{try{<code>}catch{<в журнал>}} внутри имеют — вообще печально.

К сожалению — вопрос не праздный — имеем сторонние библиотеки с такой фигней. Приходится бороться.

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

N_P>Тогда будет организован пул подписчиков, который все равно придется чистить от зависших подписчиков. И убивать их потоки. Оно, конечно, лучше, но в итоге все равно приходим к .Abort() или .Interrupt(). А если они еще и loop{try{<code>}catch{<в журнал>}} внутри имеют — вообще печально.

N_P>К сожалению — вопрос не праздный — имеем сторонние библиотеки с такой фигней. Приходится бороться.

Ну так и я тоже о реалиях. А мне в ответ умствования. Может хостить такие сборки в отдельный домен? Если что выгружать домен.

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

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

N_P>>Тогда будет организован пул подписчиков, который все равно придется чистить от зависших подписчиков. И убивать их потоки. Оно, конечно, лучше, но в итоге все равно приходим к .Abort() или .Interrupt(). А если они еще и loop{try{<code>}catch{<в журнал>}} внутри имеют — вообще печально.

N_P>>К сожалению — вопрос не праздный — имеем сторонние библиотеки с такой фигней. Приходится бороться.

___>Ну так и я тоже о реалиях. А мне в ответ умствования. Может хостить такие сборки в отдельный домен? Если что выгружать домен.

Да нет, все правильно народ пишет — просто вопрос — насколько оно вам критично. А то может и просто Abort() сгодится. Иногда подходит хорошо — пофигу мне уже на состояние программы при нажатии на крестик окна. А ждать минуту, пока он в сеть закончит лезть — я не хочу.

По теме — у нас было хуже — unmanaged код, отдельные домены не помогают. Сделали сервер-клиент. Приложение запускает иное под.приложение, в котором работает библиотека. Если за заданный интервал ответа нет — под.приложение убивается и перезапускается. Но у нас скорость не сильно поджимала.

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

_FR>>Если вы боитесь, что подписчики могут "зависнуть" и нарушить работу вашего кода, организуйте работу с ними по-другому: публикуйте данные о событии в некоторой очереди и пускай подписчики сами читают из неё. Только тогда их "зависоны" не будут вас беспокоить.

N_P>Тогда будет организован пул подписчиков, который все равно придется чистить от зависших подписчиков. И убивать их потоки. Оно, конечно, лучше, но в итоге все равно приходим к .Abort() или .Interrupt(). А если они еще и loop{try{<code>}catch{<в журнал>}} внутри имеют — вообще печально.

Нет, вы как-то не правильно поняли предложенное мной.

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

_FR>>>Если вы боитесь, что подписчики могут "зависнуть" и нарушить работу вашего кода, организуйте работу с ними по-другому: публикуйте данные о событии в некоторой очереди и пускай подписчики сами читают из неё. Только тогда их "зависоны" не будут вас беспокоить.

N_P>>Тогда будет организован пул подписчиков, который все равно придется чистить от зависших подписчиков. И убивать их потоки. Оно, конечно, лучше, но в итоге все равно приходим к .Abort() или .Interrupt(). А если они еще и loop{try{<code>}catch{<в журнал>}} внутри имеют — вообще печально.

_FR>Нет, вы как-то не правильно поняли предложенное мной.

Тогда поясните, пожалуйста, подробнее — я так понял, что предлагается иметь несколько экземпляров обработчиков, которые получают данные из входной очереди и выдают их в выходную. Само исходное событие отвязывается от обработчиков и кладет данные в эту самую входную очередь. Это самое положение в очередь и обработка в обработчиках — в разных потоках.

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

_FR>>>>Если вы боитесь, что подписчики могут "зависнуть" и нарушить работу вашего кода, организуйте работу с ними по-другому: публикуйте данные о событии в некоторой очереди и пускай подписчики сами читают из неё. Только тогда их "зависоны" не будут вас беспокоить.

N_P>>>Тогда будет организован пул подписчиков, который все равно придется чистить от зависших подписчиков. И убивать их потоки. Оно, конечно, лучше, но в итоге все равно приходим к .Abort() или .Interrupt(). А если они еще и loop{try{<code>}catch{<в журнал>}} внутри имеют — вообще печально.

_FR>>Нет, вы как-то не правильно поняли предложенное мной.

N_P>Тогда поясните, пожалуйста, подробнее — я так понял, что предлагается иметь несколько экземпляров обработчиков, которые получают данные из входной очереди и выдают их в выходную. Само исходное событие отвязывается от обработчиков и кладет данные в эту самую входную очередь. Это самое положение в очередь и обработка в обработчиках — в разных потоках.

Мы рассматриваем "серверный" код, который поставляет информацию. "несколько экземпляров обработчиков" серверу иметь совершенно не нужно. Просто в некую очеред сервер отправляет данные о том, что у него произошло. "Очередь" по сути — это данные, которые никак не могут "зависнуть". Никаких "входных"-"выходных". Тем же, кому интересно следить за событиями сервера, "клиенты" читают из этой очереди.

В простейшем случае, очередь — это List<Tuple<int, SomeEventArgs>>, где int — это инкрементальный счётчик. сервер дабавляет в этот список объекты SomeEventArgs, а клиент запрашивает объекты, у которых int больше того, что клиент получил в последний раз.

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

_FR>Мы рассматриваем "серверный" код, который поставляет информацию. "несколько экземпляров обработчиков" серверу иметь совершенно не нужно. Просто в некую очеред сервер отправляет данные о том, что у него произошло. "Очередь" по сути — это данные, которые никак не могут "зависнуть". Никаких "входных"-"выходных". Тем же, кому интересно следить за событиями сервера, "клиенты" читают из этой очереди.

_FR>В простейшем случае, очередь — это List<Tuple<int, SomeEventArgs>>, где int — это инкрементальный счётчик. сервер дабавляет в этот список объекты SomeEventArgs, а клиент запрашивает объекты, у которых int больше того, что клиент получил в последний раз.

Ну, я думаю, что не хорошо сужать ситуацию до чисто-абстрактного варианта. Автора-то, небось, комплексное решение интересует, а не одна строна медали. Кто-то же обеспечивает работу\связь всех этих клиентов. Сейчас у автора проблема в логике сервера по вызову функций\событий клиентов (1 штука и более), будет проблема в логике все того же сервера, но уже по работе с экземплярами\соединениями клиентов. Ему придется как минимум отслеживать переполнение входной очереди, особенно, если в аргументах что-то тяжелое, а еще мониторить жизнедеятельность клиентов потому как если они по-одному постепенно все перемрут — ничего хорошего для системы в целом не будет даже при том, что аргументы для этих клиентов будут продолжать класться в очередь без проблем

P.S. Я, может, перестраховщик, но, кажется мне, что это не простой случай, когда у автора все хорошо, а он не догадался как данные загружать и обрабатывать в 2х разных потоках при работе через события.

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

_FR>>Мы рассматриваем "серверный" код, который поставляет информацию. "несколько экземпляров обработчиков" серверу иметь совершенно не нужно. Просто в некую очеред сервер отправляет данные о том, что у него произошло. "Очередь" по сути — это данные, которые никак не могут "зависнуть". Никаких "входных"-"выходных". Тем же, кому интересно следить за событиями сервера, "клиенты" читают из этой очереди.

_FR>>В простейшем случае, очередь — это List<Tuple<int, SomeEventArgs>>, где int — это инкрементальный счётчик. сервер дабавляет в этот список объекты SomeEventArgs, а клиент запрашивает объекты, у которых int больше того, что клиент получил в последний раз.

N_P>Ну, я думаю, что не хорошо сужать ситуацию до чисто-абстрактного варианта. Автора-то, небось, комплексное решение интересует, а не одна строна медали.

Я не представляю себе, что такое "чисто-абстрактного" и чем это отличается от "абстрактного" ИМХО, вполне конкретный совет как серверу не зависеть от зависонов клиентов.

N_P>…а еще мониторить жизнедеятельность клиентов

Как раз таки от необходимости мониторить клиентов я автора и избавляю.

А следить за тем, что бы очередь не переполнилась — совсем не сложно. Это отдельная тема обсуждения. Но она не критична в данном вопросе.

N_P>>Ну, я думаю, что не хорошо сужать ситуацию до чисто-абстрактного варианта. Автора-то, небось, комплексное решение интересует, а не одна строна медали.

_FR>Я не представляю себе, что такое "чисто-абстрактного" и чем это отличается от "абстрактного" ИМХО, вполне конкретный совет как серверу не зависеть от зависонов клиентов.

А кто, кроме автора, будет за ними следить ? Не понимаю я вашей точки зрения. Как именно вы "от необходимости мониторить клиентов я автора и избавляю" ? КТО конкретно будет заниматься задачей мониторинга ?

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

N_P>>>Ну, я думаю, что не хорошо сужать ситуацию до чисто-абстрактного варианта. Автора-то, небось, комплексное решение интересует, а не одна строна медали.
_FR>>Я не представляю себе, что такое "чисто-абстрактного" и чем это отличается от "абстрактного" ИМХО, вполне конкретный совет как серверу не зависеть от зависонов клиентов.

N_P>А кто, кроме автора, будет за ними следить ? Не понимаю я вашей точки зрения. Как именно вы "от необходимости мониторить клиентов я автора и избавляю" ? КТО конкретно будет заниматься задачей мониторинга ?

Ещё раз: я как раз и предлагаю автору отказаться от мониторинга сервером клиентов. Необходимость мониторить клиентов (отслеживать, что они живы и как-то вызывтаь их) делает сервер менее стабильным, ибо стабильность сервера ничинает зависеть от стабильности клиентов.

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

N_P>>>>Ну, я думаю, что не хорошо сужать ситуацию до чисто-абстрактного варианта. Автора-то, небось, комплексное решение интересует, а не одна строна медали.
_FR>>>Я не представляю себе, что такое "чисто-абстрактного" и чем это отличается от "абстрактного" ИМХО, вполне конкретный совет как серверу не зависеть от зависонов клиентов.

N_P>>А кто, кроме автора, будет за ними следить ? Не понимаю я вашей точки зрения. Как именно вы "от необходимости мониторить клиентов я автора и избавляю" ? КТО конкретно будет заниматься задачей мониторинга ?

_FR>Ещё раз: я как раз и предлагаю автору отказаться от мониторинга сервером клиентов. Необходимость мониторить клиентов (отслеживать, что они живы и как-то вызывтаь их) делает сервер менее стабильным, ибо стабильность сервера ничинает зависеть от стабильности клиентов.

Бррр... А что будет, если они-таки повиснут намертво ?

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

N_P>>>>>Ну, я думаю, что не хорошо сужать ситуацию до чисто-абстрактного варианта. Автора-то, небось, комплексное решение интересует, а не одна строна медали.
_FR>>>>Я не представляю себе, что такое "чисто-абстрактного" и чем это отличается от "абстрактного" ИМХО, вполне конкретный совет как серверу не зависеть от зависонов клиентов.

N_P>>>А кто, кроме автора, будет за ними следить ? Не понимаю я вашей точки зрения. Как именно вы "от необходимости мониторить клиентов я автора и избавляю" ? КТО конкретно будет заниматься задачей мониторинга ?

_FR>>Ещё раз: я как раз и предлагаю автору отказаться от мониторинга сервером клиентов. Необходимость мониторить клиентов (отслеживать, что они живы и как-то вызывтаь их) делает сервер менее стабильным, ибо стабильность сервера ничинает зависеть от стабильности клиентов.

N_P>Бррр... А что будет, если они-таки повиснут намертво ?

Кто? Если подвиснут клиенты, то только им от это хуже и будет — на производительности сервера или других клиентов это никоим образом не скажется.

В данный же момент подвисший клиаент "съедает" поток сервера. серверу необходимо его абортить, что во-первых приведёт к неясно каким плачевным результатам, а, во-вторых, вынуждает на каждый вызов клиента отводить отдельный поток (ибо абортить потоки из системного пула уж очень не красиво) или создавать собственный пул. И то, и другое — раскладывание граблей.

_FR>>>Ещё раз: я как раз и предлагаю автору отказаться от мониторинга сервером клиентов. Необходимость мониторить клиентов (отслеживать, что они живы и как-то вызывтаь их) делает сервер менее стабильным, ибо стабильность сервера ничинает зависеть от стабильности клиентов.

N_P>>Бррр... А что будет, если они-таки повиснут намертво ?

_FR>Кто? Если подвиснут клиенты, то только им от это хуже и будет — на производительности сервера или других клиентов это никоим образом не скажется.

_FR>В данный же момент подвисший клиаент "съедает" поток сервера. серверу необходимо его абортить, что во-первых приведёт к неясно каким плачевным результатам, а, во-вторых, вынуждает на каждый вызов клиента отводить отдельный поток (ибо абортить потоки из системного пула уж очень не красиво) или создавать собственный пул. И то, и другое — раскладывание граблей.

Эту часть вашей точки зрения я понял — я не понимаю — что автор будет делать, когда при сдаче программы заказчику на большой выборке все клиенты повиснут и обработка встанет ? Я полагаю, что фраза "я сервер писал — к серверу притензии есть ?" не сойдет за удовлетворительное оправдание. Особенно, если разработку клиентов не удастся спихнуть на какого лоха и придется делать самому.

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

N_P>…я не понимаю — что автор будет делать, когда при сдаче программы заказчику на большой выборке все клиенты повиснут и обработка встанет ?

А почему _все_ подвиснут А почему это проблема топикстартера

В любом случае, разбираться с тем, почему зависают клиенты придётся — какое это имеет отношение к том, что и как делать с сервером?

N_P>Я полагаю, что фраза "я сервер писал — к серверу притензии есть ?" не сойдет за удовлетворительное оправдание. Особенно, если разработку клиентов не удастся спихнуть на какого лоха и придется делать самому.

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

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

N_P>Эту часть вашей точки зрения я понял — я не понимаю — что автор будет делать, когда при сдаче программы заказчику на большой выборке все клиенты повиснут и обработка встанет ? Я полагаю, что фраза "я сервер писал — к серверу притензии есть ?" не сойдет за удовлетворительное оправдание. Особенно, если разработку клиентов не удастся спихнуть на какого лоха и придется делать самому.
Судя по вопросу ТС, для него работоспособность "основного цикла" важнее, чем работоспособность "подписчиков".
Предположим, основной цикл занимается обсчётом 3d-порно, а "подписчик" всего лишь пишет логи прогресса.

Наивная реализация с if(OnProgress!=null) OnProgress(this) означает, что неудачный подписчик поставит всё колом, и порно так и не сольётся в экстазе.

Реализация с Abort() пристрелит лог-райтер (если он затупил), но продолжит рендер.

В реализации, которую предлагает Fred, рендеру вообще всё равно, есть там подписчики или нету. Он молотит в своём темпе.
Лог-райтер, который, возможно, пытается доставить логи по сетке, и у него тут локальный отказ случился на 20 секунд, имеет шанс проснуться и догнать. Или не проснуться — это его проблема. Поток рендера не бегает за ним с таймером и абортом в руке.