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

A>По ссылке просто презентация доклада о Framework 4.0,
A>Основную фразу, в контексте нашего разговора, я оттуда уже привел.

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

J>За это спасибо.
J>В контексте нашего разговора — как Вы считаете, имеет смысл ли смысл ловить OutOfMemoryException на самом верхнем уровне? В смысле, на уровне соединения в сервере, дабы закрыть его и позволить остальным клиентам обслуживаться нормально? Если да, то есть ли какие-то подводные камни?

Если вы работаете с большими объемами (иными словами, если появление этого исключения хоть сколько-нибудь ожидаемо), то нужно.
Подводных камней тут не вижу.

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

J>Может. Уверенности нет. Просто объекты с финализатором (коим является SafeHandle сидящий внутри сокета) в нулевом поколении не собираются.

SafeHandle это не просто объект с финализацией, это еще и CriticalFinalizerObject

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

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

J>>Может. Уверенности нет. Просто объекты с финализатором (коим является SafeHandle сидящий внутри сокета) в нулевом поколении не собираются.

AVK>SafeHandle это не просто объект с финализацией, это еще и CriticalFinalizerObject

Я так понимаю это не отменяет того факта, что он не собирается в нулевом поколении? Или я что-то упустил?

Y>>Один хрен, ему дали сокетом попользоваться, а он его прибивает.
TK>А с "гвоздями" такой use-case вас тоже удивляет?

Я не знаю, что такое "гвозди", но если Вы имеете в виду гвозди, то их забивают.

Y>>Вам же не приходит в голову сказать, что объект создает конструктор.
TK>Конструктор занимается только инициализацией экземпляра. Никто не запрещает создавать "не инициализированные" экземпляры.

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

J>Такие примеры в FCL еще есть.

Честно говоря, я не знаю, из каких соображений так сделано. (Вы знаете, зачем?)
Но то, что про эти "особенности" приходится знать, меня напрягает.

Y>>Передавайте коннекшену саму фабрику или на худой конец, "фабричный делегат", если уж всё именно так, как Вы задумали.
J>Зачем такие сложности? Какие я получу от этого преимущества в моем коде?

Не такие уж и сложности. Ваш коннекшн получит единовластное (а не "на правах последнего") пользование коннекшеном, если это Вам действительно нужно.

PS
Я не исключаю, что не улавливаю тонкую разницу между вызовом полноценного деструктора и метода Dispose()

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

J>Этой ситуации просто не может быть. За мои 10 лет кодирования, я ни разу не применял ни TerminateThread(), ни Thread.Abort() и надеюсь сохранить достаточную трезвость ума, чтоб не применять их и в будущем . Все мои серверные приложения жили (некоторые живут до сих пор) счастливо. Наверное я что-то делал неправильно (с).

вот ты несколькими постами выше писал про синдром "бакалавра"? а за собой сего не замечаешь? цитата выше является классическим образчиком.
где ты был когда "любимая" тобою тема (Thred.Abort) обсуждалась_здесь

Автор:
Дата: 13.03.09

? где те, умные советы которыми стОило поделится?
не поленись, прокомментируй пост

Автор:
Дата: 13.03.09

AVK>>SafeHandle это не просто объект с финализацией, это еще и CriticalFinalizerObject

J>Я так понимаю это не отменяет того факта, что он не собирается в нулевом поколении? Или я что-то упустил?

Нет, не отменяет.

Однако есть гарантия, что handle рано или поздно обязательно освободится. В версии Fw 1.1 это не гарантировалось.

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

A>Однако есть гарантия, что handle рано или поздно обязательно освободится. В версии Fw 1.1 это не гарантировалось.

У вас какое-то неправильное впечатление об первой версии framework. Финализатор мог не вызваться только некоторых случаях при завершении процесса. CriticalFinalizerObject позволяет обработать лишь некоторые из них. Однако, полной гарантии не дает и он.

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

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

A>>Однако есть гарантия, что handle рано или поздно обязательно освободится. В версии Fw 1.1 это не гарантировалось.

TK>У вас какое-то неправильное впечатление об первой версии framework. Финализатор мог не вызваться только некоторых случаях при завершении процесса.
Именно это я и имел ввиду.

TK>CriticalFinalizerObject позволяет обработать лишь некоторые из них. Однако, полной гарантии не дает и он.
Можете привести пример, в котором не будет вызван Finalize у SafeHandle.

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

А>не поленись, прокомментируй пост

Автор:
Дата: 13.03.09

Thread.Abort не будет абортить "зависшие" операции ввода/вывода и unmanaged треды.

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

TK>>CriticalFinalizerObject позволяет обработать лишь некоторые из них. Однако, полной гарантии не дает и он.
A>Можете привести пример, в котором не будет вызван Finalize у SafeHandle.

Вариантов полно — от снятия процесса, до power-off

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

TK>Thread.Abort не будет абортить "зависшие" операции ввода/вывода и unmanaged треды.

в курсе, это уже детали. а как быть например с длительными "управляемыми" операциями?

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

TK>>Thread.Abort не будет абортить "зависшие" операции ввода/вывода и unmanaged треды.
А>в курсе, это уже детали. а как быть например с длительными "управляемыми" операциями?

Длительные "управляемые" операции надо соответствующим образом проектировать так, что-бы Thread.Abort для их прерывания не требовался. Если же эти операции "падают" с неба то, выносите их в отдельный процесс — потенциальных проблем будет сильно меньше.

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

TK>Длительные "управляемые" операции надо соответствующим образом проектировать так, что-бы Thread.Abort для их прерывания не требовался. Если же эти операции "падают" с неба то, выносите их в отдельный процесс — потенциальных проблем будет сильно меньше.

вот, оказывается вы невнимательно читали пост, ссылку на который я дал. дам же написано кое-что кроме базы данных — создание отчета. а конкретно Crystal Reports (впрочем неважно). Как предлагаете мне управлять стороенней библиотекой и длительность выполнения операции, в частности создания отчета, которая (операция) может растянутся на минуты?

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

А>вот, оказывается вы невнимательно читали пост, ссылку на который я дал. дам же написано кое-что кроме базы данных — создание отчета. а конкретно Crystal Reports (впрочем неважно). Как предлагаете мне управлять стороенней библиотекой и длительность выполнения операции, в частности создания отчета, которая (операция) может растянутся на минуты?

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

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

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

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

з.ы. я считаю, что это распростаненный способ, взгляните хотя бы на svchost и его предназначение, а также сколько сервисов он хостит

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

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

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

А>ну, их много. для каждого писАть солюшены, запускающее приложение и всю "инфраструктуру" слишком тяжко.

Ну это один раз сделать надо, а потом жить счастливо.

А>тогда как в нынешнем виде вообще все реализовано в виде плагинов, проблему отваливания решаю посредством загрузки каждого сервиса в собственный домен.

Странно тогда, что файлы остаются залоченными при выгрузке домена. Как тут уже писали, это CriticalFinalizerObject, он должен почиститься

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

J>Ну это один раз сделать надо, а потом жить счастливо.
.., а потом поддерживать в каждом. да ну нафик такую перспективу.

J>Странно тогда, что файлы остаются залоченными при выгрузке домена. Как тут уже писали, это CriticalFinalizerObject, он должен почиститься

ну на тот момент была не решена, тогда временно сделал через GC.Collect (рабочий вариант кстати), потом плагинную архитектуру реализовал, щас в процессе вндерения "доменности" плагинов

з.ы. вот один фиг, спать не дает Thread.Abort, а ниче не поделаешь

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

А>з.ы. вот один фиг, спать не дает Thread.Abort, а ниче не поделаешь

Я с CrystalReport не работал, оно что совсем никак не дает отменить начатую долгую операцию?