В процитированном коде что-то не так :-)
// Никаких параметров, этот метод должен освобождать только неуправляемые ресурсы
protected virtual void DisposeManagedResources() {}
Касательно (***). Так не просто такой же синтаксис, они и называются деструкторами, хотя делают не тоже самое.
Ну так асинхронный I/O .Net — это обёртка над IOCP, Socket.BeginSend/Socket.BeginReceive.
HttpListener это вообще не API ввода-вывода, вы там с HttpListenerContext работаете и уже распарсенным HttpListenerRequest. Никакого Read/Receive или Write/Send там нет. HttpListener — это расширяемая платформа веб-сервера.
Что касается неуместного выпада в сторону .Net… Ты серьёзно бротюнь?
С10К задача решаемая веб-сервером, в данном случае IIS (Hostable WebCore, http.sys), а не языком программирования или платчормой. Apache (написанный на Си) или TomCat не справляются с ней точно так же как и IIS, как, впрочем, и любой другой сервер приложений. Язык тут не при чём.
Добавлю к словам предыдущих комментаторов, что множество полезной и корректной информации можно найти по адресу www.1024cores.net/
Есть англоязычный и русскоязычный разделы, а сам автор русскоязычный.
Ну вот смотри. У тебя написано “при возникновении любого исключения в некотором методе, состояние программы должно оставаться согласованным” и в качестве примера для нарушения базовой гарантии использование IDisposable и отсутствие вызова Dispose().
Я бы привёл другой пример, где исключение вызывает не отсутствие вызова Dispose(), а его неправильную работу, из-за несогласованности полей класса. Собственно, это как раз то для чего нужен CER. Что-то вроде
class DisposableX: IDisposable
{
DisposableX()
{
_handleA = OpenHandle(...);
// Тут исключение по любой причине.
_handleB = OpenHandle(_handleA, ...);
}
void Dispose()
{
CloseHandle(_handleB); // ага, сейчас, он же IntPtr.Zero.
CloseHandle(_handleA);
}
ИМХО перепутаны два понятия, согласованность состояния и освобождение ресурсов.
1) То что Dispose() не будет вызван при возникновении исключения в конструкторе мешает освобождать ресурсы своевременно, но не мешает поддерживать согласованное состояние программы.
2) Dispose(), в отличие от деструктора Си++, обычный метод который можно вызвать обычным образом. Ничто не мешает вручную написать try/finally вручную вызывать Dispose() самостоятельно. Более того, try/catch можно написать в конструкторе и вызвать Dispose() из catch. причём одно не исключает друогого, так как Dispose() по спецификации может быть вызван многократно.
3) Ну и самое главное замечание, можно сказать что в статье есть фактическая ошибка. В C# есть то, чего нет в Си++, Constrained Execution Regions. Это как раз возможность множество операций объединить в непрерываемый исключениями блок операций. Так что далеко не только присваивание ссылки может быть использовано.
Лицензией. GPL вообще не вариант. LGPL многие боятся. Есть фирмы где LGPL код запрещено даже читать. Мой выбор — New BSD, я не жадный и коммерческие форки меня не вгоняют в депрессию.
А зачем мне отказываться от решения без ограничений ради решения с ограничениями? Да, решения Aspose и IndependentSoft платные, но в отличие от вашего они доступны. Никто не раскроет исходники, тем более под GPL, ради такой прикладной задачи как экспорт в DOCX. Ваш проект под текущей лицензией малополезен. И если с СОМ+ ещё понятно в чём проблема, то чем ваш продукт лучше OpenXML SDK, Aspose Words, Word.Net вы не рассказали.
lwn.net/Articles/318611/
В процитированном коде что-то не так :-)
// Никаких параметров, этот метод должен освобождать только неуправляемые ресурсы
protected virtual void DisposeManagedResources() {}
Касательно (***). Так не просто такой же синтаксис, они и называются деструкторами, хотя делают не тоже самое.
В примечении (****) нет ссылки на материал о CER.
HttpListener это вообще не API ввода-вывода, вы там с HttpListenerContext работаете и уже распарсенным HttpListenerRequest. Никакого Read/Receive или Write/Send там нет. HttpListener — это расширяемая платформа веб-сервера.
msdn.microsoft.com/en-us/library/system.net.httplistener.aspx
Нарошной ститьи я сейчас с ходу не нашёл, но по ссылкам ниже упоминается использование HTTP.sys и вызванные этим особенности.
msdn.microsoft.com/en-us/library/ms733768.aspx
msdn.microsoft.com/en-us/magazine/cc163570.aspx
tomasz.janczuk.org/2009/08/performance-of-http-polling-duplex.html
результаты замеров. Банально Worker Threads заканчиваются.
Что касается неуместного выпада в сторону .Net… Ты серьёзно бротюнь?
С10К задача решаемая веб-сервером, в данном случае IIS (Hostable WebCore, http.sys), а не языком программирования или платчормой. Apache (написанный на Си) или TomCat не справляются с ней точно так же как и IIS, как, впрочем, и любой другой сервер приложений. Язык тут не при чём.
2) Неоптимальная синхронизация. lock не нужен для чтения примитивных типов, а для записи вместо него достаточен вызов Thread.MemoryBarrier()
У UltraVNC есть открытый www.uvnc.com/downloads/mirror-driver.html
Есть англоязычный и русскоязычный разделы, а сам автор русскоязычный.
Я бы привёл другой пример, где исключение вызывает не отсутствие вызова Dispose(), а его неправильную работу, из-за несогласованности полей класса. Собственно, это как раз то для чего нужен CER. Что-то вроде
class DisposableX: IDisposable
{
DisposableX()
{
_handleA = OpenHandle(...);
// Тут исключение по любой причине.
_handleB = OpenHandle(_handleA, ...);
}
void Dispose()
{
CloseHandle(_handleB); // ага, сейчас, он же IntPtr.Zero.
CloseHandle(_handleA);
}
}
1) То что Dispose() не будет вызван при возникновении исключения в конструкторе мешает освобождать ресурсы своевременно, но не мешает поддерживать согласованное состояние программы.
2) Dispose(), в отличие от деструктора Си++, обычный метод который можно вызвать обычным образом. Ничто не мешает вручную написать try/finally вручную вызывать Dispose() самостоятельно. Более того, try/catch можно написать в конструкторе и вызвать Dispose() из catch. причём одно не исключает друогого, так как Dispose() по спецификации может быть вызван многократно.
3) Ну и самое главное замечание, можно сказать что в статье есть фактическая ошибка. В C# есть то, чего нет в Си++, Constrained Execution Regions. Это как раз возможность множество операций объединить в непрерываемый исключениями блок операций. Так что далеко не только присваивание ссылки может быть использовано.
www.microsoft.com/download/en/details.aspx?displaylang=en&id=5124
не говоря уже обо всяких Aspose и IndependentSoft
А ваше в коммерческих приложениях использовать не получится.
3. Уместно применённый синглтон, только stateless.