Как правильно использовать 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>Можно конечно его стартовать в отдельном потоке, но в итоге мы быстро очень быстро упремся в ограничение по памяти.
L>>А какое поведение по-вашему должно быть в случае зависшего handler-а? L>>Можно конечно его стартовать в отдельном потоке, но в итоге мы быстро очень быстро упремся в ограничение по памяти.
___>Зависший убивать Abort-ом.
А как отличить зависший от долго-работающего? Не говоря уж о том, что Abort — это не кошерно.
Здравствуйте, Lloyd, Вы писали:
___>>Зависший убивать Abort-ом.
L>А как отличить зависший от долго-работающего? Не говоря уж о том, что Abort — это не кошерно.
Здравствуйте, Аноним, Вы писали:
А>Как правильно использовать Eventы в Thread ? А>Например в таком коде
А>Проблема возникает если в обработчике eventa происходит исключение или зависание, это нарушает работу потока, а по идее он должен работать не зависимо от работоспособности подписчиков. От эксепшенов еще можно спастись обернув вызов в try catch., а вот от зависонов не совсем понятно как.
А зачем избавляться "от зависонов" Если они в принципе есть, то рано или поздно зависнет каждый имеющийся у вас поток.
Если вы боитесь, что подписчики могут "зависнуть" и нарушить работу вашего кода, организуйте работу с ними по-другому: публикуйте данные о событии в некоторой очереди и пускай подписчики сами читают из неё. Только тогда их "зависоны" не будут вас беспокоить.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _d_m_, Вы писали:
L>>А как отличить зависший от долго-работающего? Не говоря уж о том, что Abort — это не кошерно.
___>Это вопрос к автору топика.
Да нет, именно к тебе. Технически зависший поток ничем не отличается от долгоработающего.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, _d_m_, Вы писали:
L>>>А как отличить зависший от долго-работающего? Не говоря уж о том, что Abort — это не кошерно.
___>>Это вопрос к автору топика.
L>Да нет, именно к тебе. Технически зависший поток ничем не отличается от долгоработающего.
Нет к автору. Я ж не знаю что у него там за "зависшие потоки".
Здравствуйте, _d_m_, Вы писали:
L>>А какое поведение по-вашему должно быть в случае зависшего handler-а? L>>Можно конечно его стартовать в отдельном потоке, но в итоге мы быстро очень быстро упремся в ограничение по памяти.
___>Зависший убивать Abort-ом.
Это очень плохой способ, тем более, когда не известно, чем занимается убиваемый поток: например, если он внутри себя создаёт Excel.Application и "зависает" в процессе работы с ним, то при убивании потока сервер Excel.exe так и останется запущенным. Через какое-то время подобной "работы" процессов экселя может быть создано не мало, что может помешать работе системы в целом.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _d_m_, Вы писали:
L>>Да нет, именно к тебе. Технически зависший поток ничем не отличается от долгоработающего.
___>Нет к автору. Я ж не знаю что у него там за "зависшие потоки".
Раз ты предлагаешь использовать Abort для зависших, то это автоматически означает, что ты знаешь, что такое зависший поток.
Здравствуйте, Lloyd, Вы писали:
___>>Нет к автору. Я ж не знаю что у него там за "зависшие потоки".
L>Раз ты предлагаешь использовать Abort для зависших, то это автоматически означает, что ты знаешь, что такое зависший поток.
Здравствуйте, 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.
___>Какой еще нафиг процесс?
Сорри, поток.
___>Кто пишет процедуру потока?
Я не знаю, об этом в постановке не говорится.
___>Может ты доколупаешься до автора топика?
Зачем? Я же обсуждаю предложенное тобой решение, а не вопрос.
Re[2]: Event в Thread
От:
Аноним
Дата:
30.11.10 18:56
Оценка:
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, Аноним, Вы писали:
А>>Как правильно использовать Eventы в Thread ? А>>Например в таком коде
А>>Проблема возникает если в обработчике eventa происходит исключение или зависание, это нарушает работу потока, а по идее он должен работать не зависимо от работоспособности подписчиков. От эксепшенов еще можно спастись обернув вызов в try catch., а вот от зависонов не совсем понятно как.
_FR>А зачем избавляться "от зависонов" Если они в принципе есть, то рано или поздно зависнет каждый имеющийся у вас поток.
_FR>Если вы боитесь, что подписчики могут "зависнуть" и нарушить работу вашего кода, организуйте работу с ними по-другому: публикуйте данные о событии в некоторой очереди и пускай подписчики сами читают из неё. Только тогда их "зависоны" не будут вас беспокоить.
Да , второй вариант, а то что будет виснуть рабочий поток — это его проблемы и надо фиксить.
А вот если рабочий поток отлажен и подписчики вроде бы стабильно работают, то подключение к event одного "неудачника" не должно приводить к катастрофе и влиянию на работу тех кто работает корректно.
А чем плохо предложенное выше решение _d_m_ с BeginInvoke, я пока не тестировал, но подозреваю что это что-то на подобии асинхронного вызова. http://www.rsdn.ru/forum/dotnet/4058443.1.aspx
Здравствуйте, Аноним, Вы писали:
А>А вот если рабочий поток отлажен и подписчики вроде бы стабильно работают, то подключение к event одного "неудачника" не должно приводить к катастрофе и влиянию на работу тех кто работает корректно.
Если вам достаточно таких гарантий — делайте как хотите. Но, обычно, надёжность системы определяется надёжностью самого слабого звена, а не отношением количества надёжных к количеству слабых. Поэтому надёжность повышается не увеличением количества стабильных звеньев, а устранением наислабейших.
А>А чем плохо предложенное выше решение _d_m_ с BeginInvoke, я пока не тестировал, но подозреваю что это что-то на подобии асинхронного вызова. А>http://www.rsdn.ru/forum/dotnet/4058443.1.aspx
Тем, что "зависшие" потоки так и останутся висеть, занимая и занимая пул. Если вы не считаете дорогим подарить один серверный поток одному "зависшему" клиенту — сделайте так. Но почитайте, что происходит при вызове Delegate::BeginInvoke и что за потоки (откуда они берутся) будут "дариться" клиентам. Не будет ли это дорогогим ресурсом для вас?
Help will always be given at Hogwarts to those who ask for it.
Re[4]: Event в Thread
От:
Аноним
Дата:
01.12.10 11:33
Оценка:
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, _d_m_, Вы писали:
L>>>А какое поведение по-вашему должно быть в случае зависшего handler-а? L>>>Можно конечно его стартовать в отдельном потоке, но в итоге мы быстро очень быстро упремся в ограничение по памяти.
___>>Зависший убивать Abort-ом.
L>А как отличить зависший от долго-работающего? Не говоря уж о том, что Abort — это не кошерно.
а как taskManager в винде определяет, что надо писать "процесс не отвечает"?
Здравствуйте, Аноним, Вы писали:
L>>А как отличить зависший от долго-работающего? Не говоря уж о том, что Abort — это не кошерно.
А>а как taskManager в винде определяет, что надо писать "процесс не отвечает"?
Я могу только предположить, как он работает для виндовых программ. Для консольных — не ясно.
